CardinalOps Contributes Updates to MITRE ATT&CK Techniques Related to Abuse of Mail Transport Rules

Summary

This blogpost summarizes how attackers may attempt to abuse mail transport rules for malicious purposes. It provides recommended detections in the native query languages for Splunk, Microsoft Sentinel, IBM QRadar and Sumo Logic, along with their associated MITRE ATT&CK adversary techniques.

Introduction

CardinalOps’ security research team is constantly working on new ways to detect attacks based on threat actors’ activities, vulnerabilities, malware found in the wild, and more. 

During 2022, Microsoft reported multiple instances where attackers created transport rules in Office 365 instances for malicious purposes. While researching these attacks, we found gaps in ATT&CK which resulted in our team contributing multiple techniques and sub-techniques to ATT&CK v13. The updated ATT&CK techniques are:

• Hide Artifacts: Email Hiding Rules (T1564.008)
• Indicator Removal: Clear Mailbox Data (T1070.008)
• Email Collection: Email Forwarding Rule (T1114.003)
• Phishing for Information (T1598)
• Phishing (T1566)

Email Attacks

Attackers use and abuse emails during attacks in multiple ways, for different goals depending on what they’re attempting to accomplish and according to what step in the attack they are in.

In recent years, phishing attacks have been gaining popularity and increasing yearly. According to Kaspersky, in 2022 phishing attacks doubled in comparison to the previous year, reaching over 500 million phishing attempts. 

Phishing attacks can be used in multiple ways, the most common one being phishing for credentials (T1566) by sending emails with malicious attachments (T1566.001) or links (T1566.002) with the intention of either executing a malicious payload or acquiring legitimate credentials to specific systems using social engineering.

Attackers may also use emails to phish for information (T1598) during reconnaissance, prior to the attack. This technique involves the use of different types of social engineering in order to obtain data that can be used during later stages of the attack.

After an attacker gains access to an email account, they may attempt to perform actions on the mailbox itself. This is commonly used by creating mailbox rules to forward emails to internal or external recipients in order to collect specific emails (T1114.003) or to evade defenses by hiding inbound emails in a compromised user’s mailbox (T1564.008), such as hiding security alerts, C2 communication, or responses to Internal Spearphishing emails sent from the compromised account.

Mail Transport Rules

Email services such as Google Workspace, Office 365, Microsoft Exchange and Postfix allow administrators to create transport rules (called routing rules on Google Workspace). These rules enable the organization to perform automatic actions on messages that flow through the organization. Any action performed by a transport rule will be transparent to the end user.

Abusing Transport Rules

In March 2022, Microsoft published a report on the activity of DEV-0537, also known as LAPSUS$. During the attacks described in the blogpost, the attackers gained access to global admin accounts and later configured a tenant level transport rule to send all mail in and out of the organization to a newly created account (T1114.003, T1020.001).

In September 2022, Microsoft published a blogpost about how malicious OAuth applications abuse email services to spread spam. In this case the malicious actors created new transport rules and configured them to delete specific headers from any email that flowed in the organization (T1564.008, T1070.008, T1565.002).The attackers also created a new inbound connector and configured it to allow mails from specific IP addresses (related to the attacker’s infrastructure) to flow through the organization’s Exchange domain. This allowed the attackers to send spam emails to the compromised Exchange domain, remove headers that might flag the mail as suspicious, and send them to their destination as if they were sent from the compromised domain.

Transport rules have dozens of different parameters that could potentially be used by attackers in different ways such as deleting specific mail based on specific conditions (T1564.008). A list of all the different relevant parameters for Microsoft Exchange Online and local Microsoft Exchange instances can be found in Microsoft’s documentation. 

SIEM Detections for Changes to Transport Rules

In most organizations, transport rules are not created or modified on a regular basis, and therefore we advise SOC teams to monitor for any changes using the following queries:

Splunk

index=[Office 365 index] sourcetype=o365:management:activity  Operation IN ("New-TransportRule", "Set-TransportRule") ("New-TransportRule" OR "Set-TransportRule") 

| stats values(ClientIP) as ClientIP, values(Operation) as Operation, values(Parameters{}.Name) as Parameters{}.Name, values(Parameters{}.Value) as Parameters{}.Value count by UserId, ObjectId

Microsoft Sentinel

OfficeActivity

| where Operation in ("New-TransportRule", "Set-TransportRule")

| project-reorder UserId, ClientIP, Parameters

IBM QRadar

and when the event(s) were detected by one or more of Microsoft Office 365

and when the event matches Event ID is any of [New-TransportRule-true or Set-TransportRule-true]

AQL query:

select QIDNAME(qid) as "Event Name",logsourcename(logsourceid) as LogSource, username, sourceip, DATEFORMAT(startTime,'YYYY-MM-dd HH:mm:ss') as startTime from events

where devicetype=397 and qideventid in  ('New-TransportRule-true', 'Set-TransportRule-true')

Sumo Logic

_sourcecategory=O365/* ("Set-TransportRule" or "New-TransportRule")

| json field=_raw "Workload" as Workload nodrop 

| where Workload = "Exchange"

| json field=_raw "ObjectId" as ObjectId nodrop

| json field=_raw "ClientIP" as ClientIP nodrop 

| json field=_raw "UserId" as Username nodrop

| json field=_raw "Operation" as Operation nodrop

| json field=_raw "Parameters" as Parameters nodrop

| where Operation  in ("New-TransportRule", "Set-TransportRule")

| values(Parameters) as Parameters, values(ClientIP) as ClientIP by Username, ObjectId

SIEM Detections for Changes to Headers, Email Copying, and Email Forwarding 

If for some reason these events are common, it is possible to monitor for the specific parameters used to delete headers, copy or forward emails:

Splunk

index=[Office 365 index] sourcetype=o365:management:activity  Operation IN ("New-TransportRule", "Set-TransportRule") Parameters{}.Name IN ("RedirectMessageTo", "BlindCopyTo", "RemoveHeader") ("RedirectMessageTo" OR "BlindCopyTo" OR "RemoveHeader") ("New-TransportRule" OR "Set-TransportRule") 

| stats values(ClientIP) as ClientIP, values(Operation) as Operation, values(Parameters{}.Name) as Parameters{}.Name, values(Parameters{}.Value) as Parameters{}.Value count by UserId, ObjectId

Microsoft Sentinel

OfficeActivity

| where Operation in ("New-TransportRule", "Set-TransportRule")

| where Parameters has_any ("RedirectMessageTo", "BlindCopyTo", "RemoveHeader")

| project-reorder UserId, ClientIP, Parameters

IBM QRadar

and when the event(s) were detected by one or more of Microsoft Office 365

and when the event matches Event ID is any of [New-TransportRule-true or Set-TransportRule-true]

and when the event matches Parameters (custom) contains any of [RedirectMessageTo or Set-BlindCopyTo or RemoveHeader]

AQL query:

select QIDNAME(qid) as "Event Name",logsourcename(logsourceid) as LogSource, username, sourceip, DATEFORMAT(startTime,'YYYY-MM-dd HH:mm:ss') as startTime from events

where devicetype=397 and qideventid in  ('New-TransportRule-true', 'Set-TransportRule-true') and ("Parameters" ILIKE '%RedirectMessageTo%' OR "Parameters" ILIKE '%BlindCopyTo%' OR "Parameters" ILIKE '%RemoveHeader%')

Note: the field "Parameters" might be named differently in every QRadar instance. If this field is not parsed, it can be parsed using the following JSON keypath:

/"Parameters"[]

Sumo Logic

_sourcecategory=O365/* ("Set-TransportRule" or "New-TransportRule") ("BlindCopyTo" or "RedirectMessageTo" or "RemoveHeader")

| json field=_raw "Workload" as Workload nodrop 

| where Workload = "Exchange"

| json field=_raw "ObjectId" as ObjectId nodrop

| json field=_raw "ClientIP" as ClientIP nodrop 

| json field=_raw "UserId" as Username nodrop

| json field=_raw "Operation" as Operation nodrop

| json field=_raw "Parameters" as Parameters nodrop

| where Operation  in ("New-TransportRule", "Set-TransportRule")

| where Parameters contains "BlindCopyTo" or Parameters contains  "RedirectMessageTo" or Parameters contains  "RemoveHeader"

| values(Parameters) as Parameters, values(ClientIP) as ClientIP by Username, ObjectId

SIEM Detections for Changes to Connectors

In most organizations, Exchange connectors are not created or modified on a regular basis and therefore we advise SOC teams to monitor for any change using the following query:

Splunk

index=[Office 365 index] sourcetype=o365:management:activity  Operation IN ("New-InboundConnector", "Set-InboundConnector", "New-OutboundConnector", "Set-OutboundConnector") ("New-InboundConnector" OR "Set-InboundConnector", OR "New-OutboundConnector" OR "Set-OutboundConnector") 

| stats values(ClientIP) as ClientIP, values(Operation) as Operation, values(Parameters{}.Name) as Parameters{}.Name, values(Parameters{}.Value) as Parameters{}.Value count by UserId, ObjectId

Microsoft Sentinel

OfficeActivity

| where Operation in ("New-InboundConnector", "Set-InboundConnector", "New-OutboundConnector", "Set-OutboundConnector")

| project-reorder UserId, OfficeObjectId, ClientIP, Parameters

IBM QRadar

and when the event(s) were detected by one or more of Microsoft Office 365

and when the event matches Event ID is any of [New-InboundConnector-true or Set-InboundConnector-true or New-OutboundConnector-true or Set-OutboundConnector-true]

AQL query:

select QIDNAME(qid) as "Event Name",logsourcename(logsourceid) as LogSource, username, sourceip, DATEFORMAT(startTime,'YYYY-MM-dd HH:mm:ss') as startTime from events

where devicetype=397 and qideventid in  ('New-InboundConnector-true', 'Set-InboundConnector-true', 'New-OutboundConnector-true', 'Set-OutboundConnector-true')

Sumo Logic

_sourcecategory=O365/* ("Set-InboundConnector" or "New-InboundConnector" or "New-OutboundConnector" or "Set-OutboundConnector")

| json field=_raw "Workload" as Workload nodrop 

| where Workload = "Exchange"

| json field=_raw "ObjectId" as ObjectId nodrop

| json field=_raw "ClientIP" as ClientIP nodrop 

| json field=_raw "UserId" as Username nodrop

| json field=_raw "Operation" as Operation nodrop

| json field=_raw "Parameters" as Parameters nodrop

| where Operation  in ("New-InboundConnector", "Set-InboundConnector", "New-OutboundConnector", "Set-OutboundConnector")

| values(Parameters) as Parameters, values(ClientIP) as ClientIP by Username, ObjectId

Conclusions

Preventing breaches starts with having the right detections in the SOC – and the SIEM is often the last line of defense for detecting attacks missed by other security tools. 

Threat actors are increasingly targeting email systems as a mechanism for reconnaissance, as well as for gaining footholds in organizations from which they can send emails that appear to be from a trusted source.

If you’re looking for an automated solution to continuously identify and remediate detection coverage gaps in your SIEM based on MITRE ATT&CK, check out CardinalOps’ detection posture management platform and the use cases it addresses for your SOC.