Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works]

[nterl0k]

Details

This is a generic password spray detection that can be used across all CIM compliant authentication sources.

Works based on a failure to success ratios common with malicious password guessing and can be run at longer durations to catch subtle password guessing attempts. (low/slow)

Sample data provided in splunk/attack_data#851 as an internal test case, but also works well against external facing authentication data sources (VPNs, webportals, etc)

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.

[patel-bhavin]

Hello @nterl0k : It looks like we already have a similar detection for detections/endpoint/detect_password_spray_attack_behavior_from_source.yml,. Can you perhaps remove this detection from this PR and then we can work towards getting this this detection Detect Password Spray Attack On User tested and merged!

https://research.splunk.com/application/086ab581-8877-42b3-9aee-4a7ecb0923af/
https://research.splunk.com/application/b1a82fc8-8a9f-4344-9ec2-bde5c5331b57/

[patel-bhavin]

Also, we recently updated our Github CI to run build and unit-testing on all PRs. When I look at the build failure, it looks like the yaml is incorrect. :

[nterl0k]

Not sure what that screenshot is telling me, worked fine in local execution The detection I wrote was a bit different, but I'll remove it for argument sake. Regards, Steven.

…

-------- Original message -------- From: Bhavin Patel ***@***.***> Date: 7/23/24 1:55 PM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Mention ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) Also, we recently updated our Github CI to run build and unit-testing on all PRs. When I look at the build failure, it looks like the yaml is incorrect. : image.png (view on web)<https://github.com/user-attachments/assets/f72acaab-180d-4eb7-8476-83d5848552be> — Reply to this email directly, view it on GitHub<#2915 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7SHWA45YZICJXHYBHDZN2KIZAVCNFSM6AAAAABJOCDRM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBVHA4DMMJRGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ljstella]

I think the detections are different enough from the others we already have that keeping them is probably worth it.

...from_source is currently blocked on the same issue in contentctl that another one of your PRs is blocked on: splunk/contentctl#204
Essentially, some of the fields are not always present. In the sample dataset for that one, user is an empty field. There's only one result though so the fix proposed in contentctl won't actually fix that for this one. Easiest way to fix that is ensure there's a successful logon in that dataset that will be aggregated into the conditions.

...on_user has an issue with the link to the attack_data for it. I've tested it with the dataset for ...from_source in case that was the intended dataset, but that dataset doesn't actually have the right conditions to pass the math in your | where statement.

[nterl0k]

Interesting... Maybe I forgot to update the dataset for _user I thought I did but it's been a busy few months. Lemme look at it and test local again. Regards, Steven.

…

-------- Original message -------- From: Lou Stella ***@***.***> Date: 7/29/24 12:29 PM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Mention ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) I think the detections are different enough from the others we already have that keeping them is probably worth it. ...from_source is currently blocked on the same issue in contentctl that another one of your PRs is blocked on: splunk/contentctl#204<splunk/contentctl#204> Essentially, some of the fields are not always present. In the sample dataset for that one, user is an empty field. There's only one result though so the fix proposed in contentctl won't actually fix that for this one. Easiest way to fix that is ensure there's a successful logon in that dataset that will be aggregated into the conditions. ...on_user has an issue with the link to the attack_data for it. I've tested it with the dataset for ...from_source in case that was the intended dataset, but that dataset doesn't actually have the right conditions to pass the math in your | where statement. — Reply to this email directly, view it on GitHub<#2915 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7VHYBEA5F4BKUHHG2TZOZUU5AVCNFSM6AAAAABJOCDRM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJWGM4DIOBYHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nterl0k]

Either way, looks like I need to tweak the dataset to keep _source from failing contentctl

…

________________________________ From: Steven D ***@***.***> Sent: Monday, July 29, 2024 12:55 PM To: splunk/security_content ***@***.***>; splunk/security_content ***@***.***> Cc: Mention ***@***.***> Subject: RE: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) Interesting... Maybe I forgot to update the dataset for _user I thought I did but it's been a busy few months. Lemme look at it and test local again. Regards, Steven.

-------- Original message -------- From: Lou Stella ***@***.***> Date: 7/29/24 12:29 PM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Mention ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) I think the detections are different enough from the others we already have that keeping them is probably worth it. ...from_source is currently blocked on the same issue in contentctl that another one of your PRs is blocked on: splunk/contentctl#204<splunk/contentctl#204> Essentially, some of the fields are not always present. In the sample dataset for that one, user is an empty field. There's only one result though so the fix proposed in contentctl won't actually fix that for this one. Easiest way to fix that is ensure there's a successful logon in that dataset that will be aggregated into the conditions. ...on_user has an issue with the link to the attack_data for it. I've tested it with the dataset for ...from_source in case that was the intended dataset, but that dataset doesn't actually have the right conditions to pass the math in your | where statement. — Reply to this email directly, view it on GitHub<#2915 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7VHYBEA5F4BKUHHG2TZOZUU5AVCNFSM6AAAAABJOCDRM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJWGM4DIOBYHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nterl0k]

@ljstella I added a log to the data source that should help clear the contentctl errors on both, also fixed the data source link on _user to point to the correct location (derp)

splunk/attack_data#904

For _source

For _user

[ljstella]

@nterl0k weird question- in the environment that you developed this in, did you have a non-stock CIM config or something?

One of the detections is passing now, but detect_password_spray_attack_behavior_on_user.yml is not. And its an odd reason that it is not. Splunk authentications are being mapped to the Authentication datamodel, and in the test environment, we use the account admin which is also the account name in your attack data that meets the conditions for the detection. However, the extra logins from the admin user in Splunk as part of the testing workflow throws the math off, so no results end up showing up. There's a few options here to account for this:

• we can move Authentication.app to the by clause, and adjust the rest of the search as necessary, accounting for spraying against the same app instead of all apps (probably okay since we're really targetting devices, even if the logic is portable to other services?)
• we can specifically remove it with Authentication.app!='splunk'
• we can keep it the same and try to change the default username in our testing infrastructre. (cc: @pyth0n1c for this bit, haven't looked to see how impossible that would be) edit: I don't think is actually even configurable in the underlying splunk-ansible project from what I can see.

[nterl0k]

Lol.... I could also drop new data that uses a different user besides admin? I can Search/Replace like a champ. Regards, Steven.

…

-------- Original message -------- From: Lou Stella ***@***.***> Date: 8/7/24 11:00 AM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Mention ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) @nterl0k<https://github.com/nterl0k> weird question- in the environment that you developed this in, did you have a non-stock CIM config or something? One of the detections is passing now, but detect_password_spray_attack_behavior_on_user.yml is not. And its an odd reason that it is not. Splunk authentications are being mapped to the Authentication datamodel, and in the test environment, we use the account admin which is also the account name in your attack data that meets the conditions for the detection. However, the extra logins from the admin user in Splunk as part of the testing workflow throws the math off, so no results end up showing up. There's a few options here to account for this: * we can move Authentication.app to the by clause, and adjust the rest of the search as necessary, accounting for spraying against the same app instead of all apps (probably okay since we're really targetting devices, even if the logic is portable to other services?) * we can specifically remove it with Authentication.app!='splunk' * we can keep it the same and try to change the default username in our testing infrastructre. (cc: @pyth0n1c<https://github.com/pyth0n1c> for this bit, haven't looked to see how impossible that would be) — Reply to this email directly, view it on GitHub<#2915 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7U3QAM75QQF2VYAJM3ZQIZALAVCNFSM6AAAAABJOCDRM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZTGY4DGNBZHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ljstella]

If you want to, go right ahead and I'll merge it as soon as it comes in. I know this particular set of detections has already been a handful when it comes to data, but it has also shown us some of the... odd assumptions we've made, and where they break things.

[nterl0k]

Can do, gimme a little bit to update the dataset and retest local.

…

________________________________ From: Lou Stella ***@***.***> Sent: Wednesday, August 7, 2024 11:20 AM To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>; Mention ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) If you want to, go right ahead and I'll merge it as soon as it comes in. I know this particular set of detections has already been a handful when it comes to data, but it has also shown us some of the... odd assumptions we've made, and where they break things. — Reply to this email directly, view it on GitHub<#2915 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7TS2QPKX7LDZQZQYQLZQI3KRAVCNFSM6AAAAABJOCDRM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZTG4ZDMNBYGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nterl0k]

Did the thing splunk/attack_data#905

[ljstella]

Wooo! All tests passed, putting this in the queue for release! Thanks again @nterl0k

[nterl0k]

Woohooo

…

________________________________ From: Lou Stella ***@***.***> Sent: Wednesday, August 7, 2024 4:06 PM To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>; Mention ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1110.003 [Spray and Pray] or [Boring but Works] (PR #2915) Wooo! All tests passed, putting this in the queue for release! Thanks again @nterl0k<https://github.com/nterl0k> — Reply to this email directly, view it on GitHub<#2915 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7W7HQLF2VR3OZNTV7LZQJ44FAVCNFSM6AAAAABJOCDRM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZUGI2TQMBZG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ljstella]