Investigating Forwarding Rule Alerts on Shared Mailboxes

a-question-well-posed-is-a-problem-half-solved-investigating-mailbox-forwarding-alerts-on-shared-ma

This past week, I was asked:

“How can I improve my ability to determine if a user-based alert is truly malicious or suspicious — without having to reach out to the user every time?”

My response was a variation of the famous quote by Charles Kettering:

“A problem well-stated is a problem half solved.”

I told them:

“A question well-posed is a problem half solved.”

Let's Make that Practical

How does that work in a practical scenario?

Let’s say you receive the below alert from Microsoft Defender for Cloud Apps in your SIEM:

O365 Alert: Suspicious Mailbox forwarding rule on a shared mailbox.

In the alert details, you see:

• An IP address

• Account name

• Forwarding rule destination

The first thing we would want to do is form a hypothesis. It doesn’t matter what stance you take, just make sure it’s valid.

Let's say that the hypothesis I choose to form in response to the details provided by the alert is:

The forwarding rule created was benign

Within the context of the alert, benign would mean what?

Answers to the 2 below investigative questions would help us prove or disprove our hypothesis that it is likely benign.

Investigative Question 1:

1. Was the rule was created by someone internal with authorization to perform such an action and is this account compromised?

Pivoting on sign-in logs from your company's IDP and filtering based on IP address specified in the alert. We would be able to see the user and device associated with IP address. If the device field contains the id of a company owned device, that tells us it was performed by someone internal. If the device field is empty and the IP address is anomalous for the user, it may be less likely it is benign.

Investigative Question 2:

2. Does the forwarding rule itself appear suspicious?

Some examples of suspicious behaviors:

• The rule forwards emails externally (possible DLP concern).

• The destination is a newly created account (could indicate staging/exfil or persistence).

• The domain is a personal email provider like Gmail, Yahoo, or Outlook.

This is where business context matters because what is an event of interest varies from one organization to another.

If the emails are being forwarded externally and that's not normal for your org, then that may cause us to lean towards believing that the activity is malicious.

Conversely, maybe your organization does expect certain departments to have external forwarding to trusted vendors, banks or businesses and in that case it may be benign.

But if you see personal email domains such as Outlook, Gmail, Yahoo, ProtonMail and other personal email domains then that may cause us to lean towards the alert being malicious.

Even if it’s forwarding internally, it’s still worth checking whether the internal account is:

• Recently created

• Not assigned to any known team or business unit

• Showing signs of suspicious behavior (e.g., elevated permissions, mailbox rules, MFA registration anomalies)

So what's the main takeaway?

This process highlights the power of asking the right question from the start. When the analyst asked me how he could determine if a user-based alert was truly malicious without reaching out to the user, what he really needed was a framework. Instead of throwing the kitchen sink at the problem — checking logs at random, over-investigating, or escalating too early; he learned to use the right utensils  — starting with a clear, testable hypothesis and asking the right investigative questions. It streamlines a triage process and gives more confidence — all without having to involve the user.

It takes time for this process to become second nature, but use it because it's worth it. If this methodology does interest you though, it may be worth checking out the Applied Network Defense - Investigation Theory course.