Add "Inactive Account Have Activity Detected"

[zake1god]

Details

This PR introduces a new detection for Inactive User Have Activity Detected. This detection identifies users who have been inactive for more than 30 days and suddenly have activity based on network traffic logs.

Screenshots/Examples :

---

Checklist

• [x] Validate name matches <platform>_<mitre att&ck technique>_<short description> nomenclature
• [x] CI/CD jobs passed ✔️
• [x] Validated SPL logic.
• [x] Validated tags, description, and how to implement.
• [x] Verified references match analytic.
• [x] 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, it's 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.

[zake1god]

Detection Metadata Validation: ❌ ESCU - Detect Risky SPL using Pretrained ML Model - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Path traversal SPL injection - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Persistent XSS in RapidDiag through User Interface Views - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk Absolute Path Traversal Using runshellscript - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk Account Discovery Drilldown Dashboard Disclosure - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk App for Lookup File Editing RCE via User XSLT - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk Authentication Token Exposure in Debug Log - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk Code Injection via custom dashboard leading to RCE - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk Command and Scripting Interpreter Delete Usage - Rule 🔸 Detection from previous build not found in current build. ❌ ESCU - Splunk Command and Scripting Interpreter Risky Commands - Rule

Somebody can help me to fix this issue ? @patel-bhavin @ljstella 

[ljstella]

Hey @zake1god - as I mentioned in the other PR, those errors will appear until we merge https://github.com/splunk/security_content/pull/3149 - There are also possibly going to be errors as we merge other PRs and have updated our contentctl tooling this morning. We will work with you to get these all cleaned up just as soon as we can.

[patel-bhavin]

Yes, like @ljstella mentioned - we are working on getting tooling and git actions a bit straightened out. We will keep you updated! and thank you contributing to security_content!

[patel-bhavin]

Hello @zake1god : thank you for your patience! We have recently updated our tooling and have some general feedback about the detection. I will leave some inline comments on how we can improve this before we ship this detection.

[patel-bhavin]

Hello @zake1god : based on this CI failure: https://github.com/splunk/security_content/actions/runs/11487045805/job/31970703528?pr=3160

You likely need to update the file name to match the detection name Also, update the filter name in the search itself. That said, do you have any raw events that we can use for this data for testing ?

[zake1god]

Hi @patel-bhavin i already update the file name to match the detection name, and already update filter name. For raw events i can't get but i can create it. it must be like this { "_time": 1698004800, "All_Traffic.authserver": "authserver1", "All_Traffic.vendor_product": "VPN Solution", "All_Traffic.user": "user1", "All_Traffic.action": "login", "sourcetype": "net_traffic", "source": "firewall_logs", "host": "fw01" } { "_time": 1697832000, "All_Traffic.authserver": "authserver2", "All_Traffic.vendor_product": "VPN Solution", "All_Traffic.user": "user2", "All_Traffic.action": "logout", "sourcetype": "net_traffic", "source": "firewall_logs", "host": "fw01" } { "_time": 1697745600, "All_Traffic.authserver": "authserver1", "All_Traffic.vendor_product": "Network Access", "All_Traffic.user": "user3", "All_Traffic.action": "login", "sourcetype": "net_traffic", "source": "network_logs", "host": "fw02" } { "_time": 1697669200, "All_Traffic.authserver": "authserver2", "All_Traffic.vendor_product": "Firewall Solution", "All_Traffic.user": "user4", "All_Traffic.action": "login", "sourcetype": "net_traffic", "source": "firewall_logs", "host": "fw02" } { "_time": 1697414400, "All_Traffic.authserver": "authserver3", "All_Traffic.vendor_product": "Proxy Solution", "All_Traffic.user": "user5", "All_Traffic.action": "login", "sourcetype": "net_traffic", "source": "proxy_logs", "host": "proxy01" }

[zake1god]

Already fix some wrong code in title and in body

[zake1god]

Did i need to fix something? Already got All checks have passed @patel-bhavin @ljstella

[patel-bhavin]

Hello @zake1god - seems like this detection is now passing build action, however, its still failing on unit-testing action as there is no associated attack data. We store this attack_data in another open source repo : You can add your data set in here with help of a PR. We would like raw network events that can be parsed into splunk. You can check out our repo in here- : https://github.com/splunk/attack_data/tree/master/datasets/suspicious_behaviour.

Example of attack data link in the detection yaml.

We would need raw events that are associated with this detection to test this detection. Would you be able to dump that from any test splunk instance? Also, can you please attach a screenshot of the search execution?

[zake1god]

Hi @ljstella thankyou for your review. Already change it, and i open PR in Splunk/Attack_Data in here : https://github.com/splunk/attack_data/pull/912

[patel-bhavin]

@zake1god : Nice work on addressing the comment and the attack data PR.

We would need _raw events from a sourcetype that maps to the network traffic datamodel : ex - Palo Alto Logs.

A json file like the one you submitted would not work with our testing pipeline. Can you share what sourcetype did you use to develop this search? Can you perhaps share an raw events from that environment that can help trigger this detection in a splunk instance?

The attack data PR you created looks good but we will will need raw events to successfully test this detection!

[patel-bhavin]

also, I am curious that you have mentioned these in the data_sources field. Do these map to the network traffic data model?

• Windows Event Log Security 4624
• Windows Event Log Security 4625

I see that your detection uses authserver as a field but it is not available in the datamodel https://docs.splunk.com/Documentation/CIM/5.3.2/User/NetworkTraffic

[zake1god]

Omg, when i go verification again its wrong target. My bad, i'm so sorry for this. Let me close this and if i have another idea i will resubmit again. Thankyou for your knowledge @patel-bhavin