Exchange user restricted from receiving emails but not sending

Posted by Ok-Influence-2162@reddit | sysadmin | View on Reddit | 24 comments

Earlier today, a user had their email compromised and a few hundred spam emails were sent out. Thankfully, it looks like our service, proofpoint, quarantined all of these emails before they actually went out.

I went through the process of changing the users password and reapproving the email in Microsoft Defender.

My current issue is the user is able to send email but not receive any. I've confirmed their email inbox is not full, ive tried with apple mail, the outlook app and on the outlook website trying to receive inbound mail but none of it seems to be working.

Does anyone have any idea what our issue is here?

[-]

HerfDog58@reddit

Check rules on the mailbox; it's a good idea to use the Powershell cmdlets for that, as there's a parameter that lets you search for hidden rules you might not see thru the GUI.

[-]

Ok-Influence-2162@reddit (OP)

I have the issue fixed through the outlook GUI but ran the powershell commands as well to double check, this is all i am seeing:

PS /Users/j****> Get-InboxRule -Mailbox "s****@*****.com" -IncludeHidden

Name Enabled Priority RuleIdentity

---- ------- -------- ------------

Junk E-mail Rule True 1 68019#############

I am assuming I should be all set? Are there any other things I can do in Powershell to verify nothing else has been compromised? I am not a sysadmin so i'm kind of flying blind here.

[-]

fp4@reddit

If you add “ | fl” to the end of that command it’ll show you the description of what the rule is doing.

[-]

HerfDog58@reddit

That outcome should eliminate mailbox rules as a culprit.

Do a mail trace with that user mailbox as a recipient, and check the status of messages inbound to it. Examine some of those messages thru the Explorer in the Exchange Admin center, and run the Header Analyzer against them - that will let you determine if there's an issue caused by SPF/DKIM/DMARC settings, and give you the Spam Confidence Level score.

Check your mail flow rules and anti-spam policies to determine how granular a job they're doing, and whether this mailbox is caught up in those settings impacting mail.

[-]

CraigAT@reddit

This, listen the attacker will set a role to delete incoming email - so the user doesn't see any bounce backs or replies from the stuff the attacker is sending out.

[-]

Garix@reddit

Sometimes it just takes a bit to be unblacklisted across the public stack/exchange

[-]

sryan2k1@reddit

What do the message traces look like both on the proofpoint side and on the M365 side?

[-]

Ok-Influence-2162@reddit (OP)

The message trace in Exchange admin is showing the messages as delivered but to the Folder: Deleted Items.

And i do see the emails in there. Do you know why this is happening?

[-]

Frothyleet@reddit

Very likely, yes. You have not remediated the compromise. Have you checked their inbox rules? Message trace should be telling you that is the reason, in fact.

SOP for business email compromise - to try and hide the comp, attackers immediately create inbox rules to hide/delete incoming mail (so no "hey bob you might be comp'd" messages come through.

[-]

anmghstnet@reddit

What do you do to monitor for malicious rules? Is there something in defender for that?

[-]

Frothyleet@reddit

It's possible, but we have a couple of 3rd party tools that look for those kinds of signals (Arctic Wolf's MDR service is our primary).

[-]

sryan2k1@reddit

You need to look at all mail rules from powershell to find hidden ones the attacker may have set up

[-]

Apprehensive_Let1840@reddit

I've had this happen and it was the holds box which is hidden and will go up to 100GB (so twice the exchange limit) you need to check your policy retention rules. We have had two that were hard to clean so we just turned if off.

User get-mailstats with Write-Host "RecoverableItemsQuota: $($stats.RecoverableItemsQuota)" and Write-Host "RecoverableItemsWarningQuota: $($stats.RecoverableItemsWarningQuota)"

[-]

littleko@reddit

Check if Microsoft put a sending/receiving restriction on the mailbox after the compromise. This happens automatically sometimes when Defender flags an account. Go to the Microsoft 365 Defender portal > Restricted entities and see if the user is listed there.

If they're not there, check mail flow rules in Exchange admin center, sometimes compromise remediation creates a block rule that stops inbound delivery. We see this with our clients all the time after account takeovers.

[-]

iceph03nix@reddit

I'd look for mail forwarding rules, that feels like something is grabbing their incoming mail and doing something with it.

Look in the outlook web interface

[-]

basec0m@reddit

Check forwarding from outlook online

[-]

cubic_sq@reddit

Possibly the threat actor still has persistence

Block the account and engage a tenant digital forensics specialist.

Fwiw, our checklist for a possible compromise is now over 100 items in the tenant, can often take most of the day to properly investigate.

[-]

h3dwig0wl1974@reddit

We've seen a few compromised accounts with rules that either forward messages to another address or delete them altogether. Have you checked the 'deleted items' folder?

[-]

Ok-Influence-2162@reddit (OP)

Yes the emails are in the deleted items folder. Where would i look to turn this off?

[-]

h3dwig0wl1974@reddit

Glad you were able to fix the issue!

[-]

Winter_Engineer2163@reddit

This sounds like something is still blocking or redirecting inbound mail after the compromise, not a client issue.

First thing I’d check is mailbox rules. Very common after a breach to have a hidden rule that deletes or moves incoming mail, sometimes marks it as read and hides it. That alone can make it look like nothing is being received.

Also check Defender quarantine. After spam activity, inbound mail can start getting flagged more aggressively.

Run a message trace, that will tell you quickly if mail is actually delivered, quarantined, or blocked before reaching the mailbox.

Another thing to check is forwarding. Sometimes attackers set forwarding so mail is going somewhere else.

If I had to guess, it’s either a leftover inbox rule or messages getting quarantined after the incident.

[-]