0xC0FFEEEE - O365 Suspicious Mailbox Rule Created

[0xC0FFEEEE]

Details

Adding a detection for a common technique employed during BEC.

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

Associated test data - splunk/attack_data#962

[patel-bhavin]

Hello @0xC0FFEEEE : Thank you for the PR! We have a similar detection in the repo - O365 New Email Forwarding Rule Created . Curious to know if we can improve the current one here :

security_content/detections/cloud/o365_new_email_forwarding_rule_created.yml

Line 9 in a339415

description: The following analytic identifies the creation of new email forwarding

[0xC0FFEEEE]

Hey @patel-bhavin

I think the intent of this detection is different enough that both can co-exist.

I created this one with the specific aim of alerting on the defense evasion technique T1564.008, whereas the existing detection covers T1114.003.

It's also worth pointing out that the brilliant and prolific @nterl0k has an open PR #3292 with a very similar detection as well. I've tested both side by side against our production data and mine produced fewer false positives over a 7 day period by quite a margin, something like 350 vs 5.

Happy to take your lead, but I think it might be challenging to merge both, or all 3 detections without muddying the waters between two very different attacker intents.

I think there's potentially a place for all 3, with @nterl0k's as a hunting rule, thoughts?

[nterl0k]

Ironically the situation that 0xC0FFEEEE's rule detects is the exact situation I developed my rule for... But I didn't want to restrict it to a very specific actor TTP. I agree with 0xC0FFEEEE, I'm happy to tag mine as a hunting rule since it's pretty wide in its coverage.

…

-------- Original message -------- From: 0xC0FFEEEE ***@***.***> Date: 2/18/25 6:53 PM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Mention ***@***.***> Subject: Re: [splunk/security_content] 0xC0FFEEEE - O365 Suspicious Mailbox Rule Created (PR #3336) Hey @patel-bhavin<https://github.com/patel-bhavin> I think the intent of this detection is different enough that both can co-exist. I created this one with the specific aim of alerting on the defense evasion technique T1564.008, whereas the existing detection covers T1114.003. It's also worth pointing out that the brilliant and prolific @nterl0k<https://github.com/nterl0k> has an open PR #3292<#3292> with a very similar detection as well. I've tested both side by side against our production data and mine produced fewer false positives over a 7 day period by quite a margin, something like 350 vs 5. Happy to take your lead, but I think it might be challenging to merge both, or all 3 detections without muddying the waters between two very different attacker intents. I think there's potentially a place for all 3, with @nterl0k<https://github.com/nterl0k>'s as a hunting rule, thoughts? — Reply to this email directly, view it on GitHub<#3336 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7X3JUQJCRYRZHIMML32QPBXTAVCNFSM6AAAAABXFLN2ICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRXGE4DENRSGE>. You are receiving this because you were mentioned.Message ID: ***@***.***> [0xC0FFEEEE]0xC0FFEEEE left a comment (splunk/security_content#3336)<#3336 (comment)> Hey @patel-bhavin<https://github.com/patel-bhavin> I think the intent of this detection is different enough that both can co-exist. I created this one with the specific aim of alerting on the defense evasion technique T1564.008, whereas the existing detection covers T1114.003. It's also worth pointing out that the brilliant and prolific @nterl0k<https://github.com/nterl0k> has an open PR #3292<#3292> with a very similar detection as well. I've tested both side by side against our production data and mine produced fewer false positives over a 7 day period by quite a margin, something like 350 vs 5. Happy to take your lead, but I think it might be challenging to merge both, or all 3 detections without muddying the waters between two very different attacker intents. I think there's potentially a place for all 3, with @nterl0k<https://github.com/nterl0k>'s as a hunting rule, thoughts? — Reply to this email directly, view it on GitHub<#3336 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7X3JUQJCRYRZHIMML32QPBXTAVCNFSM6AAAAABXFLN2ICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRXGE4DENRSGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[pyth0n1c]

We do not ship ANY detections enabled_by_Default.

[patel-bhavin]

@nterl0k @0xC0FFEEEE - thanks both for quickly jumping on deconflicting these detections and details. I largely agree with you both and i think @nterl0k we should make the other detection as hunting and perhaps keep all three detections. Changing this to hunting will also help simplify the purpose of different types of same analytic!

[pyth0n1c]

Just some small changes to the how to implement field.

[dluxtron]

I have no idea why I'm here right looking at this right now, but would it be possible to include the rule Name as the desc threat object like @nterl0k does?

Very good linkage, the past few campaigns I saw all reused rule names. I could see the rule names being used in threat intel.

I like these detections a lot.

[0xC0FFEEEE]

@dluxtron thanks for your feedback!

Added the rule name as a threat object as requested.

I also realized I didn't need to jump through various hoops to extract the nested Parameters.Names & Parameters.Values fieldnames/values using mvzip & mvexpand so I've simplified the SPL while I was there.