Nterl0k - T1114 Suspect 0365 Email Actions

[nterl0k]

Details

This is a set of detections aimed at elevating suspicious email behavior. Actors often use "hard delete" during mailbox compromise scenarios to evade detection/remove evidence, these detections look for behaviors related to this tactic.

• O365 Email Hard Delete Excessive Volume - Rule
  • The following analytic identifies when an O365 email account hard deletes an excessive number of emails within a short period (within 1 hour).
• O365 Email Password and Payroll Compromise Behavior - Rule
  • The following analytic identifies when an O365 email recipient receives and then deletes emails for the combination of both password and banking/payroll changes within a short period. This behavior may indicate a compromised account where the threat actor is attempting to redirect the victims payroll to an attacker controlled bank account.
• O365 Email Receive and Hard Delete Takeover Behavior - Rule
  • The following analytic identifies when an O365 email recipient receives and then deletes emails related to password or banking/payroll changes within a short period. This behavior may indicate a compromised account where the threat actor is attempting to redirect the victims payroll to an attacker controlled bank account.
• O365 Email Send and Hard Delete Exfiltration Behavior - Rule
  • The following analytic identifies when an O365 email account sends and then hard deletes an email to an external recipient within a short period (within 1 hour).
• O365 Email Send and Hard Delete Suspicious Behavior - Rule
  • The following analytic identifies when an O365 email account sends and then hard deletes email with within a short period (within 1 hour).
• O365 Email Send Attachments Excessive Volume - Rule
  • The following analytic identifies when an O365 email account sends an excessive number of email attachments to external recipients within a short period (within 1 hour).
• O365 Email New Inbox Rule Created - Rule
  • (This has overlap with existing O365 forwarding rules)
  • The following analytic identifies the creation of new email inbox rules in an Office 365 environment. It detects events logged under New-InboxRule and Set-InboxRule operations within the o365_management_activity data source, focusing on parameters that may indicate mail forwarding, removal, or obfuscation.

Pending splunk/attack_data#954

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]

But I don't want to admit IPv6 exists. :) Seems like a reasonable suggestion, I'll test it and throw it in there. Thanks

-------- Original message -------- From: 0xC0FFEEEE ***@***.***> Date: 2/14/25 5:09 PM (GMT-05:00) To: splunk/security_content ***@***.***> Cc: Steven Dick ***@***.***>, Author ***@***.***> Subject: Re: [splunk/security_content] Nterl0k - T1114 Suspect 0365 Email Actions (PR #3292) @0xC0FFEEEE requested changes on this pull request.

________________________________ In detections/cloud/o365_email_new_inbox_rule_created.yml<#3292 (comment)>:

@@ -0,0 +1,63 @@

+name: O365 Email New Inbox Rule Created +id: 449f525a-7b42-47be-96a7-d9724e336c19 +version: 1 +date: '2025-01-20' +author: Steven Dick +status: production +type: Anomaly +description: The following analytic identifies the creation of new email inbox rules in an Office 365 environment. It detects events logged under New-InboxRule and Set-InboxRule operations within the o365_management_activity data source, focusing on parameters that may indicate mail forwarding, removal, or obfuscation. Inbox rule creation is a typical end-user activity however attackers also leverage this technique for multiple reasons. +data_source: +- Office 365 Universal Audit Log +search: |- + `o365_management_activity` Workload=Exchange AND (Operation=New-InboxRule OR Operation=Set-InboxRule) Parameters{}.Name IN (SoftDeleteMessage,DeleteMessage,ForwardTo,ForwardAsAttachmentTo,RedirectTo,MoveToFolder,CopyToFolder) + | eval file_path = mvappend(MoveToFolder,CopyToFolder), recipient=mvappend(ForwardTo, ForwardAsAttachmentTo, RedirectTo), user = lower(UserId), signature = Operation, src = mvindex(split(ClientIP,":"),0), desc = Name, action = 'Parameters{}.Name' src = mvindex(split(ClientIP,":"),0) This does not handle IPv6 addresses, which appear in the logs as [2600:1700:5791:aa10:a824:8351:e038:b7fa]:30106 The following should solve this ⬇️ Suggested change - | eval file_path = mvappend(MoveToFolder,CopyToFolder), recipient=mvappend(ForwardTo, ForwardAsAttachmentTo, RedirectTo), user = lower(UserId), signature = Operation, src = mvindex(split(ClientIP,":"),0), desc = Name, action = 'Parameters{}.Name' + | eval file_path = mvappend(MoveToFolder,CopyToFolder), recipient=mvappend(ForwardTo, ForwardAsAttachmentTo, RedirectTo), user = lower(UserId), signature = Operation, src = if(match(ClientIP, "^\["), ltrim(mvindex(split(ClientIP, "]:"), 0), "["), mvindex(split(ClientIP,":"),0)), desc = Name, action = 'Parameters{}.Name' — Reply to this email directly, view it on GitHub<#3292 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJIYP7UILGFQZRKAA2HPCRT2PZSR3AVCNFSM6AAAAABVYA7IR2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMMJYHA4TENJSG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[patel-bhavin]

@nterl0k : i will troubleshoot this locally using contentctl and keep you posted as to why these are failing. Curious to know if you also leverage contentctl for testing/troubleshooting?

[nterl0k]

Honestly, probably the joins/complexity.

I tend to test primarily through the frontend and clean up anything contentctl disagrees with... yeah i'm trifling like that

[patel-bhavin]

Testing works fine locally, adding screenshots as proof!

• O365 Email Password and Payroll Compromise Behavior

[patel-bhavin]

Hello @nterl0k - Can you also add a basic data_source file for this - Office 365 Reporting Message Trace in the data sources folder . We updated our tooling to check for a valid data source file for the detections

eg: - https://github.com/splunk/security_content/blob/develop/data_sources/office_365_universal_audit_log.yml

[nterl0k]

Hello @nterl0k - Can you also add a basic data_source file for this - Office 365 Reporting Message Trace in the data sources folder . We updated our tooling to check for a valid data source file for the detections

eg: - https://github.com/splunk/security_content/blob/develop/data_sources/office_365_universal_audit_log.yml

@patel-bhavin Done

[patel-bhavin]

@nterl0k : thank you for the data source update. I made a minor change to test this via CI - adding both the datasets in the same top level key for detections that use join

[patel-bhavin]

[nterl0k]

Very cool! Thanks for suffering more of my weird content 😂