This search is used to identify user accounts that share a common password.
- Type: Anomaly
Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
- Last Updated: 2018-10-08
- Author: Jim Apger, Splunk
- ID: 31337a1a-53b9-4e05-96e9-55c934cb71d3
Kill Chain Phase
- CIS 16
1 2 3 4 5 6 7 8 `stream_http` http_content_type=text* uri=/magento2/customer/account/loginPost* | rex field=form_data "login\[username\]=(?<Username>[^& |^$]+)" | rex field=form_data "login\[password\]=(?<Password>[^& |^$]+)" | stats dc(Username) as UniqueUsernames values(Username) as user list(src_ip) as src_ip by Password |where UniqueUsernames>5 | `web_fraud___password_sharing_across_accounts_filter`
The SPL above uses the following Macros:
Note that web_fraud_-_password_sharing_across_accounts_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.
How To Implement
We need to start with a dataset that allows us to see the values of usernames and passwords that users are submitting to the website hosting the Magento2 e-commerce platform (commonly found in the HTTP form_data field). A tokenized or hashed value of a password is acceptable and certainly preferable to a clear-text password. Common data sources used for this detection are customized Apache logs, customized IIS, and Splunk Stream.
Known False Positives
As is common with many fraud-related searches, we are usually looking to attribute risk or synthesize relevant context with loosely written detections that simply detect anamoluous behavior.
Associated Analytic story
source | version: 1