From 619c86d8baa5103173d736d1433a6eeca14e0bfa Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Tue, 21 Mar 2023 09:46:12 -0600 Subject: [PATCH 01/18] Revert "Oktasaur" This reverts commit 3fd201bda68d466d9efec9eb8f27ce22f45f903e. --- ...e_and_response_for_verify_push_request.yml | 102 ------------------ ...failed_requests_to_access_applications.yml | 72 ------------- ...g_detection_with_fastpass_origin_check.yml | 2 +- ...kta_suspicious_use_of_a_session_cookie.yml | 67 ------------ ..._login_failure_with_high_unknown_users.yml | 2 +- ...insight_suspected_passwordspray_attack.yml | 2 +- 6 files changed, 3 insertions(+), 244 deletions(-) delete mode 100644 detections/experimental/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml delete mode 100644 detections/experimental/application/okta_multiple_failed_requests_to_access_applications.yml delete mode 100644 detections/experimental/application/okta_suspicious_use_of_a_session_cookie.yml diff --git a/detections/experimental/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml b/detections/experimental/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml deleted file mode 100644 index bcc6dd46bc..0000000000 --- a/detections/experimental/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml +++ /dev/null @@ -1,102 +0,0 @@ -name: Okta Mismatch Between Source and Response for Okta Verify Push Request -id: 8085b79b-9b85-4e67-ad63-351c9e9a5e9a -version: 1 -date: '2023-03-17' -author: John Murphy and Jordan Ruocco, Okta, Michael Haag, Splunk -type: TTP -datamodel: [] -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: 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. Monitor, tune and filter as needed. -references: - - https://attack.mitre.org/techniques/T1621 -tags: - analytic_story: - - Suspicious Okta Activity - - Okta MFA Exhaustion - asset_type: Infrastructure - cis20: - - CIS 3 - - CIS 5 - - CIS 16 - confidence: 80 - context: [] - dataset: [] - impact: 80 - kill_chain_phases: - - Actions on Objectives - message: A mismatch between source and response for verifying a push request has occurred for $actor.alternateId$ - mitre_attack_id: - - T1621 - nist: - - DE.CM - observable: - - name: actor.alternateId - type: User - role: - - Victim - product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud - required_fields: - - _time - - authenticationContext.externalSessionId - - eventType - - debugContext.debugData.factor - - outcome.result - - actor.alternateId - - client.device - - client.ipAddress - - client.userAgent.rawUserAgent - - debugContext.debugData.behaviors - - group_push_time - risk_score: 64 - security_domain: access diff --git a/detections/experimental/application/okta_multiple_failed_requests_to_access_applications.yml b/detections/experimental/application/okta_multiple_failed_requests_to_access_applications.yml deleted file mode 100644 index 0f20cf5db1..0000000000 --- a/detections/experimental/application/okta_multiple_failed_requests_to_access_applications.yml +++ /dev/null @@ -1,72 +0,0 @@ -name: Okta Multiple Failed Requests to Access Applications -id: 1c21fed1-7000-4a2e-9105-5aaafa437247 -version: 1 -date: '2023-03-17' -author: John Murphy, Okta, Michael Haag, Splunk -type: Hunting -datamodel: [] -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. -references: -- https://attack.mitre.org/techniques/T1538 -- https://attack.mitre.org/techniques/T1550/004 -tags: - analytic_story: - - Suspicious Okta Activity - asset_type: Infrastructure - cis20: - - CIS 3 - - CIS 5 - - CIS 16 - confidence: 70 - context: [] - dataset: [] - impact: 80 - kill_chain_phases: - - Actions on Objectives - message: Multiple Failed Requests to Access Applications via Okta for $actor.alternateId$. - mitre_attack_id: - - T1550.004 - - T1538 - nist: - - DE.CM - observable: - - name: actor.alternateId - type: User - role: - - Victim - product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud - required_fields: - - _time - - authenticationContext.externalSessionId - - targets - - actor.alternateId - - client.ipAddress - - eventType - risk_score: 56 - security_domain: access diff --git a/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml b/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml index 71ecda866d..34a9f77ecf 100644 --- a/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml +++ b/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml @@ -2,7 +2,7 @@ name: Okta Phishing Detection with FastPass Origin Check id: f4ca0057-cbf3-44f8-82ea-4e330ee901d3 version: 1 date: '2023-03-09' -author: Okta, Inc, Michael Haag, Splunk +author: Michael Haag, Splunk type: TTP datamodel: [] 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. diff --git a/detections/experimental/application/okta_suspicious_use_of_a_session_cookie.yml b/detections/experimental/application/okta_suspicious_use_of_a_session_cookie.yml deleted file mode 100644 index a3043b8a18..0000000000 --- a/detections/experimental/application/okta_suspicious_use_of_a_session_cookie.yml +++ /dev/null @@ -1,67 +0,0 @@ -name: Okta Suspicious Use of a Session Cookie -id: 71ad47d1-d6bd-4e0a-b35c-020ad9a6959e -version: 1 -date: '2023-03-17' -author: Scott Dermott and Felicity Robson, Okta, Michael Haag, Splunk -type: Hunting -datamodel: [] -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. / - - * Evaluates whether there is more than one IP and whether there is more than one OS or browser for each combination of User/Device Token.' -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 actor.alternateId - | 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 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/T1539/ -tags: - analytic_story: - - Suspicious Okta Activity - asset_type: Infrastructure - cis20: - - CIS 3 - - CIS 5 - - CIS 16 - confidence: 70 - context: [] - dataset: [] - impact: 80 - kill_chain_phases: - - Actions on Objectives - message: A suspicious use of a session cookie was identified by user $actor.alternateId$. - mitre_attack_id: - - T1539 - nist: - - DE.CM - observable: - - name: actor.alternateId - type: User - role: - - Victim - product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud - required_fields: - - _time - - client.ipAddress - - client.userAgent.rawUserAgent - - client.userAgent.os - - client.geographicalContext.city - - client.userAgent.browser - - device.os_platform - - debugContext.debugData.dtHash - - actor.alternateId - risk_score: 56 - security_domain: access diff --git a/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml b/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml index c978898608..2fda17bb5d 100644 --- a/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml +++ b/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml @@ -2,7 +2,7 @@ name: Okta ThreatInsight Login Failure with High Unknown users id: 632663b0-4562-4aad-abe9-9f621a049738 version: 1 date: '2023-03-09' -author: Okta, Inc, Michael Haag, Splunk +author: Michael Haag, Splunk type: TTP datamodel: [] description: The following analytic utilizes Okta's ThreatInsight to identify "Login failures with high unknown users count" and any included secondary outcome reasons. This event will trigger when a brute force attempt occurs with unknown usernames attempted. diff --git a/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml b/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml index 8c8a24aa40..fcb337b78a 100644 --- a/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml +++ b/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml @@ -2,7 +2,7 @@ name: Okta ThreatInsight Suspected PasswordSpray Attack id: 25dbad05-6682-4dd5-9ce9-8adecf0d9ae2 version: 1 date: '2023-03-09' -author: Okta, Inc, Michael Haag, Splunk +author: Michael Haag, Splunk type: TTP datamodel: [] description: The following analytic utilizes Okta's ThreatInsight to identify "PasswordSpray" and any included secondary outcome reasons. This event will trigger when a brute force attempt occurs with unknown usernames attempted. From 28cca03ede384f223b0d6c107709facaa2cc1d0f Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Wed, 22 Mar 2023 14:03:08 -0600 Subject: [PATCH 02/18] Powershell Invoke-WmiExec Usage Powershell Invoke-WmiExec Usage --- .../powershell_invoke_wmiexec_usage.yml | 56 +++++++++++++++++++ .../powershell_invoke_wmiexec_usage.test.yml | 13 +++++ 2 files changed, 69 insertions(+) create mode 100644 detections/endpoint/powershell_invoke_wmiexec_usage.yml create mode 100644 tests/endpoint/powershell_invoke_wmiexec_usage.test.yml diff --git a/detections/endpoint/powershell_invoke_wmiexec_usage.yml b/detections/endpoint/powershell_invoke_wmiexec_usage.yml new file mode 100644 index 0000000000..5896d916c5 --- /dev/null +++ b/detections/endpoint/powershell_invoke_wmiexec_usage.yml @@ -0,0 +1,56 @@ +name: PowerShell Invoke-WmiExec Usage +id: 0734bd21-2769-4972-a5f1-78bb1e011224 +version: 1 +date: '2023-03-22' +author: Michael Haag, Splunk +type: TTP +datamodel: +- Endpoint +description: This analytic detects the usage of the Invoke-WMIExec utility within PowerShell Script Block Logging (EventCode 4104). The utility is used for executing WMI commands on targets using NTLMv2 pass-the-hash authentication. +search: '`powershell` EventCode=4104 ScriptBlockText IN ("*invoke-wmiexec*") + | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `powershell_invoke_wmiexec_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. +known_false_positives: False positives should be limited as this analytic is designed to detect a specific utility. It is recommended to apply appropriate filters as needed to minimize the number of false positives. +references: + - https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-WMIExec.ps1 +tags: + analytic_story: + - Suspicious WMI Use + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 100 + context: + - Source:Endpoint + - Stage:Defense Evasion + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/invokewmiexec_windows-powershell.log + impact: 100 + kill_chain_phases: + - Exploitation + message: PowerShell was identified running a Invoke-WmiExec on $Computer$. + mitre_attack_id: + - T1047 + observable: + - name: Computer + type: Hostname + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - EventCode + - ScriptBlockText + - Computer + risk_score: 100 + security_domain: endpoint diff --git a/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml b/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml new file mode 100644 index 0000000000..fb2aaffea3 --- /dev/null +++ b/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml @@ -0,0 +1,13 @@ +name: PowerShell Invoke-WmiExec Usage Unit Test +tests: +- name: PowerShell Invoke-WmiExec Usage + file: endpoint/powershell_invoke_wmiexec_usage.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: invokewmiexec_windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/invokewmiexec_windows-powershell.log + source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: xmlwineventlog + update_timestamp: true From 453641566fc320cf7ebc45be1eac7bd5b9d9d137 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Wed, 22 Mar 2023 14:39:02 -0600 Subject: [PATCH 03/18] Remote svc here --- .../windows_remote_create_service.yml | 79 +++++++++++++++++++ .../windows_remote_create_service.test.yml | 13 +++ 2 files changed, 92 insertions(+) create mode 100644 detections/endpoint/windows_remote_create_service.yml create mode 100644 tests/endpoint/windows_remote_create_service.test.yml diff --git a/detections/endpoint/windows_remote_create_service.yml b/detections/endpoint/windows_remote_create_service.yml new file mode 100644 index 0000000000..62afe48a7e --- /dev/null +++ b/detections/endpoint/windows_remote_create_service.yml @@ -0,0 +1,79 @@ +name: Windows Remote Create Service +id: 0dc44d03-8c00-482d-ba7c-796ba7ab18c9 +version: 1 +date: '2023-03-20' +author: Michael Haag, Splunk +type: Anomaly +datamodel: +- Endpoint +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. +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 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_remote_create_service_filter`' +how_to_implement: To implement this search, it is necessary to ingest information on processes that include the name of the process responsible for the changes from your endpoints into the Endpoint data model within the Processes node. Additionally, it is recommended to confirm that the latest version of CIM App (4.20 or higher) and the latest TA for the endpoint product are installed. +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. +references: + - https://attack.mitre.org/techniques/T1543/003/ +tags: + analytic_story: + - Active Directory Discovery + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 50 + context: + - Source:Endpoint + - Stage:Defense Evasion + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1543.003/atomic_red_team/remote_service_create_windows-sysmon.log + impact: 50 + kill_chain_phases: + - Exploitation + message: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting to create a remote service. + mitre_attack_id: + - T1543 + - T1543.003 + nist: + - DE.CM + observable: + - name: user + type: User + role: + - Victim + - name: Computer + type: Hostname + role: + - Victim + - name: parent_process_name + type: Parent Process + role: + - Parent Process + - name: process_name + type: Process + role: + - Child Process + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Processes.dest + - Processes.user + - Processes.parent_process_name #parent process name + - Processes.parent_process #parent cmdline + - Processes.original_file_name + - Processes.process_name #process name + - Processes.process #process cmdline + - Processes.process_id + - Processes.parent_process_path + - Processes.process_path + - Processes.parent_process_id + risk_score: 25 + security_domain: endpoint \ No newline at end of file diff --git a/tests/endpoint/windows_remote_create_service.test.yml b/tests/endpoint/windows_remote_create_service.test.yml new file mode 100644 index 0000000000..cebe2432dc --- /dev/null +++ b/tests/endpoint/windows_remote_create_service.test.yml @@ -0,0 +1,13 @@ +name: Windows Remote Create Service Unit Test +tests: +- name: Windows Remote Create Service + file: endpoint/windows_remote_create_service.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 From 33895c6b611c342120bfd9da0e8b6fe70a467bc7 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Wed, 22 Mar 2023 15:26:46 -0600 Subject: [PATCH 04/18] invoke --- ...powershell_invoke_cimmethod_cimsession.yml | 56 +++++++++++++++++++ .../powershell_invoke_wmiexec_usage.yml | 3 +- ...shell_invoke_cimmethod_cimsession.test.yml | 13 +++++ 3 files changed, 70 insertions(+), 2 deletions(-) create mode 100644 detections/endpoint/powershell_invoke_cimmethod_cimsession.yml create mode 100644 tests/endpoint/powershell_invoke_cimmethod_cimsession.test.yml diff --git a/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml b/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml new file mode 100644 index 0000000000..88e38e7287 --- /dev/null +++ b/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml @@ -0,0 +1,56 @@ +name: PowerShell Invoke CIMMethod CIMSession +id: 651ee958-a433-471c-b264-39725b788b83 +version: 1 +date: '2023-03-22' +author: Michael Haag, Splunk +type: Anomaly +datamodel: [] +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. +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`' +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. +references: +- https://learn.microsoft.com/en-us/powershell/module/cimcmdlets/invoke-cimmethod?view=powershell-7.3 +tags: + analytic_story: + - Malicious PowerShell + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 50 + context: + - Source:Endpoint + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/4104-cimmethod-windows-powershell.log + impact: 50 + kill_chain_phases: + - Exploitation + - Installation + message: PowerShell was identified running a Invoke-CIMMethod Invoke-CIMSession on $Computer$. + mitre_attack_id: + - T1047 + nist: + - DE.CM + observable: + - name: Computer + type: Hostname + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - EventCode + - ScriptBlockText + - Computer + risk_score: 25 + security_domain: endpoint diff --git a/detections/endpoint/powershell_invoke_wmiexec_usage.yml b/detections/endpoint/powershell_invoke_wmiexec_usage.yml index 5896d916c5..33a2952d43 100644 --- a/detections/endpoint/powershell_invoke_wmiexec_usage.yml +++ b/detections/endpoint/powershell_invoke_wmiexec_usage.yml @@ -4,8 +4,7 @@ version: 1 date: '2023-03-22' author: Michael Haag, Splunk type: TTP -datamodel: -- Endpoint +datamodel: [] description: This analytic detects the usage of the Invoke-WMIExec utility within PowerShell Script Block Logging (EventCode 4104). The utility is used for executing WMI commands on targets using NTLMv2 pass-the-hash authentication. search: '`powershell` EventCode=4104 ScriptBlockText IN ("*invoke-wmiexec*") | stats count min(_time) as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText diff --git a/tests/endpoint/powershell_invoke_cimmethod_cimsession.test.yml b/tests/endpoint/powershell_invoke_cimmethod_cimsession.test.yml new file mode 100644 index 0000000000..6e1f855ed6 --- /dev/null +++ b/tests/endpoint/powershell_invoke_cimmethod_cimsession.test.yml @@ -0,0 +1,13 @@ +name: PowerShell Invoke CIMMethod CIMSession Unit Test +tests: +- name: PowerShell Invoke CIMMethod CIMSession + file: endpoint/powershell_invoke_cimmethod_cimsession.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 + update_timestamp: true From 1d156f21e2f010ff3ee8656502559d26286fe09d Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Wed, 22 Mar 2023 15:41:14 -0600 Subject: [PATCH 05/18] remoterrrr --- .../powershell_enable_powershell_remoting.yml | 57 +++++++++++++++++++ ...rshell_enable_powershell_remoting.test.yml | 13 +++++ 2 files changed, 70 insertions(+) create mode 100644 detections/endpoint/powershell_enable_powershell_remoting.yml create mode 100644 tests/endpoint/powershell_enable_powershell_remoting.test.yml diff --git a/detections/endpoint/powershell_enable_powershell_remoting.yml b/detections/endpoint/powershell_enable_powershell_remoting.yml new file mode 100644 index 0000000000..18b96f1bef --- /dev/null +++ b/detections/endpoint/powershell_enable_powershell_remoting.yml @@ -0,0 +1,57 @@ +name: Powershell Enable PowerShell Remoting +id: 40e3b299-19a5-4460-96e9-e1467f714f8e +version: 1 +date: '2023-03-22' +author: Michael Haag, Splunk +type: Anomaly +datamodel: [] +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`' +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. +references: +- https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enable-psremoting?view=powershell-7.3 +tags: + analytic_story: + - Malicious PowerShell + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 50 + context: + - Source:Endpoint + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/4104-psremoting-windows-powershell.log + impact: 50 + kill_chain_phases: + - Actions on Objectives + message: PowerShell was identified running a Invoke-PSremoting on $Computer$. + mitre_attack_id: + - T1059.001 + - T1059 + nist: + - DE.CM + observable: + - name: Computer + type: Hostname + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - EventCode + - ScriptBlockText + - Computer + risk_score: 25 + security_domain: endpoint diff --git a/tests/endpoint/powershell_enable_powershell_remoting.test.yml b/tests/endpoint/powershell_enable_powershell_remoting.test.yml new file mode 100644 index 0000000000..8af32b8498 --- /dev/null +++ b/tests/endpoint/powershell_enable_powershell_remoting.test.yml @@ -0,0 +1,13 @@ +name: Powershell Enable PowerShell Remoting Unit Test +tests: +- name: Powershell Enable PowerShell Remoting + file: endpoint/powershell_enable_powershell_remoting.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 + update_timestamp: true From 1e455f2b5ddcae27fbb9fb7fe03f9aed6210c1fb Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Wed, 22 Mar 2023 15:43:07 -0600 Subject: [PATCH 06/18] Update windows_remote_create_service.yml --- detections/endpoint/windows_remote_create_service.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/endpoint/windows_remote_create_service.yml b/detections/endpoint/windows_remote_create_service.yml index 62afe48a7e..553f249181 100644 --- a/detections/endpoint/windows_remote_create_service.yml +++ b/detections/endpoint/windows_remote_create_service.yml @@ -51,7 +51,7 @@ tags: role: - Victim - name: parent_process_name - type: Parent Process + type: Process role: - Parent Process - name: process_name From 1cbcdd9dfbaa092cb43d71e65e50b40f0b327455 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Fri, 24 Mar 2023 09:45:22 -0600 Subject: [PATCH 07/18] pwsh is life --- .vscode/security-content.code-snippets | 2 +- .../powershell_enable_powershell_remoting.yml | 2 +- ...powershell_invoke_cimmethod_cimsession.yml | 1 + .../powershell_start_or_stop_service.yml | 58 +++++++++++++++++++ .../windows_remote_create_service.yml | 2 +- ...rshell_enable_powershell_remoting.test.yml | 4 +- .../powershell_start_or_stop_service.test.yml | 13 +++++ 7 files changed, 77 insertions(+), 5 deletions(-) create mode 100644 detections/endpoint/powershell_start_or_stop_service.yml create mode 100644 tests/endpoint/powershell_start_or_stop_service.test.yml diff --git a/.vscode/security-content.code-snippets b/.vscode/security-content.code-snippets index 5331a914c5..2541633abf 100644 --- a/.vscode/security-content.code-snippets +++ b/.vscode/security-content.code-snippets @@ -180,7 +180,7 @@ " role:", " - Victim", " - name: parent_process_name", - " type: Parent Process", + " type: Process", " role:", " - Parent Process", " - name: process_name", diff --git a/detections/endpoint/powershell_enable_powershell_remoting.yml b/detections/endpoint/powershell_enable_powershell_remoting.yml index 18b96f1bef..00fceaf53f 100644 --- a/detections/endpoint/powershell_enable_powershell_remoting.yml +++ b/detections/endpoint/powershell_enable_powershell_remoting.yml @@ -1,4 +1,4 @@ -name: Powershell Enable PowerShell Remoting +name: PowerShell Enable PowerShell Remoting id: 40e3b299-19a5-4460-96e9-e1467f714f8e version: 1 date: '2023-03-22' diff --git a/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml b/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml index 88e38e7287..686d49d1f4 100644 --- a/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml +++ b/detections/endpoint/powershell_invoke_cimmethod_cimsession.yml @@ -19,6 +19,7 @@ references: tags: analytic_story: - Malicious PowerShell + - Active Directory Lateral Movement asset_type: Endpoint cis20: - CIS 3 diff --git a/detections/endpoint/powershell_start_or_stop_service.yml b/detections/endpoint/powershell_start_or_stop_service.yml new file mode 100644 index 0000000000..d55a49e71c --- /dev/null +++ b/detections/endpoint/powershell_start_or_stop_service.yml @@ -0,0 +1,58 @@ +name: PowerShell Start or Stop Service +id: 04207f8a-e08d-4ee6-be26-1e0c4488b04a +version: 1 +date: '2023-03-24' +author: Michael Haag, Splunk +type: Anomaly +datamodel: [] +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)` + | `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. +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 +tags: + analytic_story: + - Active Directory Lateral Movement + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 20 + context: + - Source:Endpoint + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/start_stop_service_windows-powershell.log + impact: 50 + kill_chain_phases: + - Actions on Objectives + message: PowerShell was identified attempting to start or stop a service on $Computer$. + mitre_attack_id: + - T1059.001 + nist: + - DE.CM + observable: + - name: Computer + type: Hostname + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - EventCode + - ScriptBlockText + - Computer + risk_score: 10 + security_domain: endpoint diff --git a/detections/endpoint/windows_remote_create_service.yml b/detections/endpoint/windows_remote_create_service.yml index 553f249181..912b64d56a 100644 --- a/detections/endpoint/windows_remote_create_service.yml +++ b/detections/endpoint/windows_remote_create_service.yml @@ -20,7 +20,7 @@ references: - https://attack.mitre.org/techniques/T1543/003/ tags: analytic_story: - - Active Directory Discovery + - Active Directory Lateral Movement asset_type: Endpoint cis20: - CIS 3 diff --git a/tests/endpoint/powershell_enable_powershell_remoting.test.yml b/tests/endpoint/powershell_enable_powershell_remoting.test.yml index 8af32b8498..c1f861b235 100644 --- a/tests/endpoint/powershell_enable_powershell_remoting.test.yml +++ b/tests/endpoint/powershell_enable_powershell_remoting.test.yml @@ -1,6 +1,6 @@ -name: Powershell Enable PowerShell Remoting Unit Test +name: PowerShell Enable PowerShell Remoting Unit Test tests: -- name: Powershell Enable PowerShell Remoting +- name: PowerShell Enable PowerShell Remoting file: endpoint/powershell_enable_powershell_remoting.yml pass_condition: '| stats count | where count > 0' earliest_time: -24h diff --git a/tests/endpoint/powershell_start_or_stop_service.test.yml b/tests/endpoint/powershell_start_or_stop_service.test.yml new file mode 100644 index 0000000000..416fa90e3f --- /dev/null +++ b/tests/endpoint/powershell_start_or_stop_service.test.yml @@ -0,0 +1,13 @@ +name: PowerShell Start or Stop Service Unit Test +tests: +- name: PowerShell Start or Stop Service + file: endpoint/powershell_start_or_stop_service.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 + update_timestamp: true From 5f4d8821dabcfadf875def7f12a2143533150cff Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Mon, 27 Mar 2023 13:54:03 -0600 Subject: [PATCH 08/18] cimstance --- ...rshell_get_ciminstance_remote_computer.yml | 54 +++++++++++++++++++ ...l_get_ciminstance_remote_computer.test.yml | 13 +++++ 2 files changed, 67 insertions(+) create mode 100644 detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml create mode 100644 tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml diff --git a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml new file mode 100644 index 0000000000..917c77b815 --- /dev/null +++ b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml @@ -0,0 +1,54 @@ +name: Windows PowerShell Get-CIMInstance Remote Computer +id: d8c972eb-ed84-431a-8869-ca4bd83257d1 +version: 1 +date: '2023-03-27' +author: Michael Haag, Splunk +type: Anomaly +datamodel: [] +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`' +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. +references: + - 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 + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 50 + context: + - Update context + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/get_ciminstance_windows-powershell.log + impact: 30 + kill_chain_phases: + - Exploitation + message: A PowerShell Cmdlet Get-CIMInstnace was ran on $Computer$, attempting to connect to a remote host. + mitre_attack_id: + - T1059.001 + nist: + - DE.CM + observable: + - name: Computer + type: Hostname + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - ScriptBlockText + - Computer + - EventCode + risk_score: 15 + security_domain: endpoint diff --git a/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml b/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml new file mode 100644 index 0000000000..e6bf314d2c --- /dev/null +++ b/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml @@ -0,0 +1,13 @@ +name: Windows PowerShell Get-CIMInstance Remote Computer Unit Test +tests: +- name: Windows PowerShell Get-CIMInstance Remote Computer + file: endpoint/windows_powershell_get_ciminstance_remote_computer.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 + update_timestamp: true From b8d61ec85c36fda6d4a398b240aedb5f578db669 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Mon, 27 Mar 2023 15:14:51 -0600 Subject: [PATCH 09/18] Create windows_enable_win32_scheduledjob_via_registry.yml --- ...enable_win32_scheduledjob_via_registry.yml | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml diff --git a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml new file mode 100644 index 0000000000..49de98c351 --- /dev/null +++ b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml @@ -0,0 +1,52 @@ +name: Windows Enable Win32_ScheduledJob via Registry +id: 12c80db8-ef62-4456-92df-b23e1b3219f6 +version: 1 +date: '2023-03-27' +author: Michael Haag, Splunk +type: TTP +datamodel: +- Endpoint +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.' +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*" 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. +references: +- REFERENCE +tags: + analytic_story: + - Active Directory Lateral Movement + asset_type: UPDATE asset_type + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: UPDATE value between 1-100 + context: + - Update context + dataset: + - UPDATE_DATASET_URL + impact: UPDATE value between 1-100 + kill_chain_phases: + - Installation + message: UPDATE message + mitre_attack_id: + - T1053.005 + nist: + - DE.CM + observable: + - name: UPDATE + type: UPDATE + role: + - UPDATE + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - UPDATE + risk_score: UPDATE (impact * confidence)/100 + security_domain: endpoint From e690fa201ce19d6ef1a374197fb4ac157e207119 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Mon, 27 Mar 2023 15:14:59 -0600 Subject: [PATCH 10/18] Update windows_powershell_get_ciminstance_remote_computer.yml --- .../windows_powershell_get_ciminstance_remote_computer.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml index 917c77b815..b766562f35 100644 --- a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml +++ b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml @@ -25,7 +25,7 @@ tags: - CIS 16 confidence: 50 context: - - Update context + - Source:Endpoint dataset: - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/get_ciminstance_windows-powershell.log impact: 30 From 1b67a2549122af5241cb2f1154e9f573f1b64f1d Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Mon, 27 Mar 2023 20:43:20 -0600 Subject: [PATCH 11/18] tasks --- ...enable_win32_scheduledjob_via_registry.yml | 37 ++++++++++++------- ...e_win32_scheduledjob_via_registry.test.yml | 13 +++++++ 2 files changed, 37 insertions(+), 13 deletions(-) create mode 100644 tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml diff --git a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml index 49de98c351..c3951a82f6 100644 --- a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml +++ b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml @@ -3,7 +3,7 @@ id: 12c80db8-ef62-4456-92df-b23e1b3219f6 version: 1 date: '2023-03-27' author: Michael Haag, Splunk -type: TTP +type: Anomaly datamodel: - Endpoint 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.' @@ -15,38 +15,49 @@ search: '| tstats `security_content_summariesonly` count values(Registry.registr 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: -- REFERENCE +- https://securityonline.info/wmiexec-regout-get-outputdata-response-from-registry/ +- https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjob tags: analytic_story: - Active Directory Lateral Movement - asset_type: UPDATE asset_type + asset_type: Endpoint cis20: - CIS 3 - CIS 5 - CIS 16 - confidence: UPDATE value between 1-100 + confidence: 50 context: - - Update context + - Source:Endpoint + - Stage:Lateral Movement dataset: - - UPDATE_DATASET_URL - impact: UPDATE value between 1-100 + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log + impact: 50 kill_chain_phases: - Installation - message: UPDATE message + message: A process has modified the schedule task registry value - EnableAt - on endpoint $dest$ by user $user$. mitre_attack_id: - T1053.005 nist: - DE.CM observable: - - name: UPDATE - type: UPDATE + - name: user + type: User role: - - UPDATE + - Victim + - name: dest + type: Hostname + role: + - Victim product: - Splunk Enterprise - Splunk Enterprise Security - Splunk Cloud required_fields: - - UPDATE - risk_score: UPDATE (impact * confidence)/100 + - _time + - Registry.registry_path + - Registry.dest + - Registry.user + - Registry.registry_value_name + - Registry.registry_value_type + risk_score: 25 security_domain: endpoint diff --git a/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml b/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml new file mode 100644 index 0000000000..acf5e99f8c --- /dev/null +++ b/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml @@ -0,0 +1,13 @@ +name: Windows Enable Win32_ScheduledJob via Registry Unit Test +tests: +- name: Windows Enable Win32_ScheduledJob via Registry + file: endpoint/windows_enable_win32_scheduledjob_via_registry.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 + update_timestamp: true From 4a9a8bea9657002dc9aa45cb989dc940c6beddca Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Mon, 27 Mar 2023 20:57:12 -0600 Subject: [PATCH 12/18] win32 pwsh --- ...dows_powershell_wmi_win32_scheduledjob.yml | 58 +++++++++++++++++++ ...powershell_wmi_win32_scheduledjob.test.yml | 13 +++++ 2 files changed, 71 insertions(+) create mode 100644 detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml create mode 100644 tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml diff --git a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml new file mode 100644 index 0000000000..fe23e730a7 --- /dev/null +++ b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml @@ -0,0 +1,58 @@ +name: Windows PowerShell WMI Win32_ScheduledJob +id: 47c69803-2c09-408b-b40a-063c064cbb16 +version: 1 +date: '2023-03-27' +author: Michael Haag, Splunk +type: TTP +datamodel: [] +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 + | `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. +references: +- https://securityonline.info/wmiexec-regout-get-outputdata-response-from-registry/ +- https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjob +tags: + analytic_story: + - Active Directory Lateral Movement + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 50 + context: + - Source:Endpoint + - Stage:Lateral Movement + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log/win32_scheduledjob_windows-powershell.log + impact: 80 + kill_chain_phases: + - Installation + message: PowerShell attempting to create a task via WMI - Win32_ScheduledJob, was ran on $dest$. + mitre_attack_id: + - T1059.001 + - T1059 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - ScriptBlockText + - dest + - EventCode + risk_score: 40 + security_domain: endpoint diff --git a/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml b/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml new file mode 100644 index 0000000000..6b5ae6b997 --- /dev/null +++ b/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml @@ -0,0 +1,13 @@ +name: Windows PowerShell WMI Win32_ScheduledJob Unit Test +tests: +- name: Windows PowerShell WMI Win32_ScheduledJob + file: endpoint/windows_powershell_wmi_win32_scheduledjob.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: win32_scheduledjob_windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log/win32_scheduledjob_windows-powershell.log + source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: xmlwineventlog + update_timestamp: true From 38d238e523f6c3d28e4ed4de50f0a2f64e0d1846 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Wed, 29 Mar 2023 20:30:07 -0600 Subject: [PATCH 13/18] tscon --- .../windows_service_create_with_tscon.yml | 81 +++++++++++++++++++ ...windows_service_create_with_tscon.test.yml | 13 +++ 2 files changed, 94 insertions(+) create mode 100644 detections/endpoint/windows_service_create_with_tscon.yml create mode 100644 tests/endpoint/windows_service_create_with_tscon.test.yml diff --git a/detections/endpoint/windows_service_create_with_tscon.yml b/detections/endpoint/windows_service_create_with_tscon.yml new file mode 100644 index 0000000000..255d1cbf32 --- /dev/null +++ b/detections/endpoint/windows_service_create_with_tscon.yml @@ -0,0 +1,81 @@ +name: Windows Service Create with Tscon +id: c13b3d74-6b63-4db5-a841-4206f0370077 +version: 1 +date: '2023-03-29' +author: Michael Haag, Splunk +type: TTP +datamodel: +- Endpoint +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.' +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 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_service_create_with_tscon_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 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. +references: +- 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 + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 80 + context: + - Source:Endpoint + - Stage:Lateral Movement + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1563.002/rdphijack/tscon_windows-sysmon.log + impact: 80 + kill_chain_phases: + - Exploitation + - Installation + message: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting to hijack a RDP session. + mitre_attack_id: + - T1563.002 + - T1563 + - T1543.003 + nist: + - DE.CM + observable: + - name: user + type: User + role: + - Victim + - name: dest + type: Hostname + role: + - Victim + - name: parent_process_name + type: Process + role: + - Parent Process + - name: process_name + type: Process + role: + - Child Process + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Processes.dest + - Processes.user + - Processes.parent_process_name #parent process name + - Processes.parent_process #parent cmdline + - Processes.original_file_name + - Processes.process_name #process name + - Processes.process #process cmdline + - Processes.process_id + - Processes.parent_process_path + - Processes.process_path + - Processes.parent_process_id + risk_score: 64 + security_domain: endpoint \ No newline at end of file diff --git a/tests/endpoint/windows_service_create_with_tscon.test.yml b/tests/endpoint/windows_service_create_with_tscon.test.yml new file mode 100644 index 0000000000..a438efa7d7 --- /dev/null +++ b/tests/endpoint/windows_service_create_with_tscon.test.yml @@ -0,0 +1,13 @@ +name: Windows Service Create with Tscon Unit Test +tests: +- name: Windows Service Create with Tscon + file: endpoint/windows_service_create_with_tscon.yml + pass_condition: '| stats count | where count > 0' + earliest_time: -24h + latest_time: now + attack_data: + - file_name: 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 + update_timestamp: true From 2f9816fe46f4cad90aaf853fc18b7c08ef687385 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Thu, 30 Mar 2023 05:05:11 -0600 Subject: [PATCH 14/18] fixes i think --- detections/endpoint/powershell_invoke_wmiexec_usage.yml | 2 +- .../windows_enable_win32_scheduledjob_via_registry.yml | 2 +- .../windows_powershell_get_ciminstance_remote_computer.yml | 2 +- .../endpoint/windows_powershell_wmi_win32_scheduledjob.yml | 2 +- tests/endpoint/powershell_invoke_wmiexec_usage.test.yml | 4 ++-- .../windows_enable_win32_scheduledjob_via_registry.test.yml | 4 ++-- ...indows_powershell_get_ciminstance_remote_computer.test.yml | 2 +- .../windows_powershell_wmi_win32_scheduledjob.test.yml | 4 ++-- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/detections/endpoint/powershell_invoke_wmiexec_usage.yml b/detections/endpoint/powershell_invoke_wmiexec_usage.yml index 33a2952d43..5748dc0530 100644 --- a/detections/endpoint/powershell_invoke_wmiexec_usage.yml +++ b/detections/endpoint/powershell_invoke_wmiexec_usage.yml @@ -1,4 +1,4 @@ -name: PowerShell Invoke-WmiExec Usage +name: PowerShell Invoke WmiExec Usage id: 0734bd21-2769-4972-a5f1-78bb1e011224 version: 1 date: '2023-03-22' diff --git a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml index c3951a82f6..4f315026af 100644 --- a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml +++ b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml @@ -1,4 +1,4 @@ -name: Windows Enable Win32_ScheduledJob via Registry +name: Windows Enable Win32 ScheduledJob via Registry id: 12c80db8-ef62-4456-92df-b23e1b3219f6 version: 1 date: '2023-03-27' diff --git a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml index b766562f35..fe2976d826 100644 --- a/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml +++ b/detections/endpoint/windows_powershell_get_ciminstance_remote_computer.yml @@ -1,4 +1,4 @@ -name: Windows PowerShell Get-CIMInstance Remote Computer +name: Windows PowerShell Get CIMInstance Remote Computer id: d8c972eb-ed84-431a-8869-ca4bd83257d1 version: 1 date: '2023-03-27' diff --git a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml index fe23e730a7..cae04d6616 100644 --- a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml +++ b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml @@ -1,4 +1,4 @@ -name: Windows PowerShell WMI Win32_ScheduledJob +name: Windows PowerShell WMI Win32 ScheduledJob id: 47c69803-2c09-408b-b40a-063c064cbb16 version: 1 date: '2023-03-27' diff --git a/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml b/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml index fb2aaffea3..546bd37549 100644 --- a/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml +++ b/tests/endpoint/powershell_invoke_wmiexec_usage.test.yml @@ -1,6 +1,6 @@ -name: PowerShell Invoke-WmiExec Usage Unit Test +name: PowerShell Invoke WmiExec Usage Unit Test tests: -- name: PowerShell Invoke-WmiExec Usage +- name: PowerShell Invoke WmiExec Usage file: endpoint/powershell_invoke_wmiexec_usage.yml pass_condition: '| stats count | where count > 0' earliest_time: -24h diff --git a/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml b/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml index acf5e99f8c..dbe0d32438 100644 --- a/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml +++ b/tests/endpoint/windows_enable_win32_scheduledjob_via_registry.test.yml @@ -1,6 +1,6 @@ -name: Windows Enable Win32_ScheduledJob via Registry Unit Test +name: Windows Enable Win32 ScheduledJob via Registry Unit Test tests: -- name: Windows Enable Win32_ScheduledJob via Registry +- name: Windows Enable Win32 ScheduledJob via Registry file: endpoint/windows_enable_win32_scheduledjob_via_registry.yml pass_condition: '| stats count | where count > 0' earliest_time: -24h diff --git a/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml b/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml index e6bf314d2c..51a0c4d222 100644 --- a/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml +++ b/tests/endpoint/windows_powershell_get_ciminstance_remote_computer.test.yml @@ -1,4 +1,4 @@ -name: Windows PowerShell Get-CIMInstance Remote Computer Unit Test +name: Windows PowerShell Get CIMInstance Remote Computer Unit Test tests: - name: Windows PowerShell Get-CIMInstance Remote Computer file: endpoint/windows_powershell_get_ciminstance_remote_computer.yml diff --git a/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml b/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml index 6b5ae6b997..bddfaf8517 100644 --- a/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml +++ b/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml @@ -1,6 +1,6 @@ -name: Windows PowerShell WMI Win32_ScheduledJob Unit Test +name: Windows PowerShell WMI Win32 ScheduledJob Unit Test tests: -- name: Windows PowerShell WMI Win32_ScheduledJob +- name: Windows PowerShell WMI Win32 ScheduledJob file: endpoint/windows_powershell_wmi_win32_scheduledjob.yml pass_condition: '| stats count | where count > 0' earliest_time: -24h From 24cd43ef4958316001b4866e9f79a6460d5bc360 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Thu, 30 Mar 2023 05:28:30 -0600 Subject: [PATCH 15/18] woops --- .../endpoint/windows_powershell_wmi_win32_scheduledjob.yml | 2 +- detections/endpoint/windows_service_create_with_tscon.yml | 3 ++- .../windows_powershell_wmi_win32_scheduledjob.test.yml | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml index cae04d6616..dfa101e220 100644 --- a/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml +++ b/detections/endpoint/windows_powershell_wmi_win32_scheduledjob.yml @@ -30,7 +30,7 @@ tags: - Source:Endpoint - Stage:Lateral Movement dataset: - - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log/win32_scheduledjob_windows-powershell.log + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/win32_scheduledjob_windows-powershell.log impact: 80 kill_chain_phases: - Installation diff --git a/detections/endpoint/windows_service_create_with_tscon.yml b/detections/endpoint/windows_service_create_with_tscon.yml index 255d1cbf32..cebf27a5c2 100644 --- a/detections/endpoint/windows_service_create_with_tscon.yml +++ b/detections/endpoint/windows_service_create_with_tscon.yml @@ -17,7 +17,8 @@ search: '| tstats `security_content_summariesonly` count min(_time) as firstTime 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 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. references: -- https://doublepulsar.com/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6 + - https://doublepulsar.com/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6 + - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1563.002/T1563.002.md tags: analytic_story: - Active Directory Lateral Movement diff --git a/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml b/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml index bddfaf8517..0a09038aba 100644 --- a/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml +++ b/tests/endpoint/windows_powershell_wmi_win32_scheduledjob.test.yml @@ -7,7 +7,7 @@ tests: latest_time: now attack_data: - file_name: win32_scheduledjob_windows-powershell.log - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/atomic_red_team/enableat_windows-sysmon.log/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 From 8974c0076c98dc20b5b25c80a80075c9f4f5599d Mon Sep 17 00:00:00 2001 From: patel-bhavin Date: Thu, 30 Mar 2023 09:13:12 -0500 Subject: [PATCH 16/18] adding baack okta --- .../okta_phishing_detection_with_fastpass_origin_check.yml | 2 +- ...okta_threatinsight_login_failure_with_high_unknown_users.yml | 2 +- .../okta_threatinsight_suspected_passwordspray_attack.yml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml b/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml index 34a9f77ecf..71ecda866d 100644 --- a/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml +++ b/detections/experimental/application/okta_phishing_detection_with_fastpass_origin_check.yml @@ -2,7 +2,7 @@ name: Okta Phishing Detection with FastPass Origin Check id: f4ca0057-cbf3-44f8-82ea-4e330ee901d3 version: 1 date: '2023-03-09' -author: Michael Haag, Splunk +author: Okta, Inc, Michael Haag, Splunk type: TTP datamodel: [] 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. diff --git a/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml b/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml index 2fda17bb5d..c978898608 100644 --- a/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml +++ b/detections/experimental/application/okta_threatinsight_login_failure_with_high_unknown_users.yml @@ -2,7 +2,7 @@ name: Okta ThreatInsight Login Failure with High Unknown users id: 632663b0-4562-4aad-abe9-9f621a049738 version: 1 date: '2023-03-09' -author: Michael Haag, Splunk +author: Okta, Inc, Michael Haag, Splunk type: TTP datamodel: [] description: The following analytic utilizes Okta's ThreatInsight to identify "Login failures with high unknown users count" and any included secondary outcome reasons. This event will trigger when a brute force attempt occurs with unknown usernames attempted. diff --git a/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml b/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml index fcb337b78a..8c8a24aa40 100644 --- a/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml +++ b/detections/experimental/application/okta_threatinsight_suspected_passwordspray_attack.yml @@ -2,7 +2,7 @@ name: Okta ThreatInsight Suspected PasswordSpray Attack id: 25dbad05-6682-4dd5-9ce9-8adecf0d9ae2 version: 1 date: '2023-03-09' -author: Michael Haag, Splunk +author: Okta, Inc, Michael Haag, Splunk type: TTP datamodel: [] description: The following analytic utilizes Okta's ThreatInsight to identify "PasswordSpray" and any included secondary outcome reasons. This event will trigger when a brute force attempt occurs with unknown usernames attempted. From 4c45077ba0adae59a0becec6de0db945dde43851 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Mon, 3 Apr 2023 06:09:19 -0600 Subject: [PATCH 17/18] Update windows_service_create_with_tscon.yml --- detections/endpoint/windows_service_create_with_tscon.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/endpoint/windows_service_create_with_tscon.yml b/detections/endpoint/windows_service_create_with_tscon.yml index cebf27a5c2..c33becef34 100644 --- a/detections/endpoint/windows_service_create_with_tscon.yml +++ b/detections/endpoint/windows_service_create_with_tscon.yml @@ -69,7 +69,7 @@ tags: - _time - Processes.dest - Processes.user - - Processes.parent_process_name #parent process name + - Processes.parent_process_name - Processes.parent_process #parent cmdline - Processes.original_file_name - Processes.process_name #process name From c98454e87911a33fde911b25a42f30f0df5f81e1 Mon Sep 17 00:00:00 2001 From: Michael Haag <5632822+MHaggis@users.noreply.github.com> Date: Tue, 4 Apr 2023 10:02:44 -0600 Subject: [PATCH 18/18] add the key --- .../endpoint/windows_enable_win32_scheduledjob_via_registry.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml index 4f315026af..54d8a4037b 100644 --- a/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml +++ b/detections/endpoint/windows_enable_win32_scheduledjob_via_registry.yml @@ -9,7 +9,7 @@ datamodel: 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.' 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*" by + 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.