Nterl0k - T1550 - NetExec Usage Detection

[nterl0k]

Details

A broad detection designed to pickup the usage of "NetExec", an updated successor to CrackMapExec. The toolkit can be built with python and renamed to whatever, so command line matching ensures accuracy.

Pending splunk/attack_data#923

Checklist

• Validate name matches <platform>_<mitre att&ck technique>_<short description> nomenclature
• CI/CD jobs passed ✔️
• Validated SPL logic.
• Validated tags, description, and how to implement.
• Verified references match analytic.
• Confirm updates to lookups are handled properly.

Notes For Submitters and Reviewers

• If you're submitting a PR from a fork, ensuring the box to allow updates from maintainers is checked will help speed up the process of getting it merged.
• Checking the output of the build CI job when it fails will likely show an error about what is failing. You may have a very descriptive error of the specific field(s) in the specific file(s) that is causing an issue. In some cases, its also possible there is an issue with the YAML. Many of these can be caught with the pre-commit hooks if you set them up. These errors will be less descriptive as to what exactly is wrong, but will give you a column and row position in a specific file where the YAML processing breaks. If you're having trouble with this, feel free to add a comment to your PR tagging one of the maintainers and we'll be happy to help troubleshoot it.
• Updates to existing lookup files can be tricky, because of how Splunk handles application updates and the differences between existing lookup files being updated vs new lookups. You can read more here but the short version is that any changes to lookup files need to bump the datestamp in the lookup CSV filename, and the reference to it in the YAML needs to be updated.

[nterl0k]

Thanks for the comments. As far as the command line false positives, I ran this back 90 days in our production network and it only triggered on the known usage of NetExec. Since NetExec currently always requires the protocol flag + a combination of the current switches, it made for a fairly robust detection. Not saying the detection logic suggestions/comment are invalid, just didn't see a need to complicate the query any further when it was pretty accurate. I'll make some edits regardless to cover the default bin name and the -m flag. The confidence and description suggests are fine I'll make those changes...and the requisite risk score change associated. Regards, Steven.

-------- Original message -------- From: Nasreddine Bencherchali ***@***.***> Date: 12/30/24 7:19 AM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Author ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1550 - NetExec Usage Detection (PR #3255) @nasbench requested changes on this pull request.

________________________________ In detections/endpoint/windows_process_with_netexec_command_line_parameters.yml<#3255 (comment)>:

+search: '| tstats `security_content_summariesonly` values(Processes.parent_process) as Processes.parent_process, values(Processes.process) as Processes.process values(Processes.process_current_directory) AS process_current_directory, values(Processes.process_id) as Processes.process_id, values(Processes.process_guid) as Processes.process_guid, count min(_time) AS firstTime, max(_time) AS lastTime FROM datamodel=Endpoint.Processes where Processes.process IN ("* smb *","* ssh *","* ldap *","* ftp *","* wmi *","* winrm *","* rdp *","* vnc *","* mssql *","* nfs *") AND Processes.process IN ("* -p *","* -u *","* -x *","* --*") BY _time span=1h Processes.user Processes.dest Processes.process_name Processes.parent_process_name

+|`drop_dm_object_name(Processes)` +| `security_content_ctime(firstTime)` +| `security_content_ctime(lastTime)` +| `windows_process_with_netexec_command_line_parameters_filter`' Hey thanks for the contribution. Just a couple of notes regarding the logic. * The rule can trigger on commands such as cmd /c or powershell -c where a user would call similar binaries on windows such as ssh (supports an -p flag) or ftp (it supports an -x flag). Its best to tune the rule to remove such cases. Since the -u and -p are almost always provided together for login. Best to group them to increase accuracy and avoid edge cases talked about above. * netexec also support modules with the -M flag. The module names can also be used as indicators and I suggest you do use them to increase coverage. * Also its best to add a standalone condition for detecting calls to nxc.exe just to cover the default case.

________________________________ In detections/endpoint/windows_process_with_netexec_command_line_parameters.yml<#3255 (comment)>:

+|`drop_dm_object_name(Processes)`

+| `security_content_ctime(firstTime)` +| `security_content_ctime(lastTime)` +| `windows_process_with_netexec_command_line_parameters_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: Although unlikely, legitimate applications may use the same command line parameters as Rubeus. Filter as needed. +references: +- https://www.netexec.wiki/ +- https://www.johnvictorwolfe.com/2024/07/21/the-successor-to-crackmapexec/ +- https://attack.mitre.org/software/S0488/ +tags: + analytic_story: + - Active Directory Kerberos Attacks + - Active Directory Privilege Escalation + asset_type: Endpoint + confidence: 100 You cannot be 100 confident using only command line flags. I would dial this down to 80 ⬇️ Suggested change - confidence: 100 + confidence: 80

________________________________ In detections/endpoint/windows_process_with_netexec_command_line_parameters.yml<#3255 (comment)>:

@@ -0,0 +1,68 @@

+name: Windows Process With NetExec Command Line Parameters +id: adbff89c-c1f2-4a2e-88a4-b5e645856510 +version: 1 +date: '2024-12-19' +author: nobody +status: production +type: TTP +description: The following analytic detects the use of NetExec (formally CrackmapExec) through command line parameters. This is a toolset for post-exploitation enumeration and attack 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 NetExec is 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. Made small adjustment in the wording to make it clearer. ⬇️ Suggested change

…

-description: The following analytic detects the use of NetExec (formally CrackmapExec) through command line parameters. This is a toolset for post-exploitation enumeration and attack 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 NetExec is 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. +description: The following analytic detects the use of NetExec (formally CrackmapExec) a toolset used for post-exploitation enumeration and attack within Active Directory environments through command line parameters. 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 NetExec is 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. — Reply to this email directly, view it on GitHub<#3255 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7RWFHBS663JQD3ETVL2IE247AVCNFSM6AAAAABUIUKQK2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMRVGUYTQMBSGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[nasbench]

make some edits regardless to c

That is good to know that you did not encounter any FPs in your env. But as I mentioned, its about edge cases and since the logic might trigger on these edge cases, its best to mitigate them before we merge. (Its about being as accurate as possible).

[nterl0k]

Yes, I have a large corporate environment available for testing. Agree, avoiding the edge cases is best, when it doesn't reduce detection efficacy. I'll get those changes made shortly, thanks for the feedback. Regards, Steven.

…

-------- Original message -------- From: Nasreddine Bencherchali ***@***.***> Date: 12/30/24 8:11 AM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Author ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1550 - NetExec Usage Detection (PR #3255) make some edits regardless to c That is good to know that you did not encounter any FPs in your env. But as I mentioned, its about edge cases and since the logic might trigger on these edge cases, its best to mitigate them before we merge. (Its about being as accurate as possible). — Reply to this email directly, view it on GitHub<#3255 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7TH6SQVEP64JFLMLLD2IFA7ZAVCNFSM6AAAAABUIUKQK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRVGQ3DMMJWGI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[nterl0k]

I've addressed your comments with updates. Thanks

[nasbench]

LGTM from a logic pov

The only thing that I noticed not only in this specific PR is the usage of the span=1h in some rules and not others. Would need to discuss this internally with the rest of the team on why this inconsistency exists.

[nterl0k]

I know ESCU content defaults to -10m/-70m, so I don't think the _time span=1hr is functionally important to the logic for this specific correlation. It just helps bubble up repeats over longer than default search times.

Feel free to nip it out to keep things consistent.

I know I've built others that have spans because the logic does uses a follow-on time based statistics/where statement.