Email Threats, Attack Simulation and Restricted Entities

Hunting email threats and training your humans

Simple explanation

Policies catch threats automatically — but you still need to investigate what gets through, simulate attacks to test your users, and deal with accounts that get compromised.

Threat Explorer is your investigation tool — it shows every email that entered your tenant and lets you trace what happened (delivered, quarantined, blocked, clicked). When you find malicious emails that slipped past defences, you can remediate them directly — soft-delete from mailboxes, move to junk, or hard-delete permanently.

Attack simulation training lets you send fake phishing emails to your own users. Those who fall for it get assigned training modules. Over time, you measure whether click rates drop.

When a compromised account starts sending spam, Exchange blocks it automatically. You manage these blocked users through the Restricted entities page.

Threat Explorer

Threat Explorer (at security.microsoft.com > Email and collaboration > Explorer) is the primary investigation tool for email threats. It provides a searchable, filterable view of all email entering your tenant.

Threat Explorer vs Real-time detections

Threat Explorer vs Real-time Detections
Feature	Threat Explorer (Plan 2)	Real-time Detections (Plan 1)
Data retention	30 days	30 days
Views available	All email, Malware, Phish, Campaigns, Content malware, URL clicks	Malware, Phish, Content malware only
Remediation actions	Soft delete, hard delete, move to junk, move to inbox	No direct remediation — manual action required
Email entity page	Full entity page with headers, URLs, attachments, delivery chain	Limited view
Campaign detection	Groups related malicious emails into campaigns for bulk analysis	Not available
Export	Export up to 200,000 results	Export up to 10,000 results

Investigating with Threat Explorer

Elena uses Threat Explorer daily at MedGuard Health. Her standard investigation workflow:

Step 1 — Filter by threat type. Select the “Phish” view to focus on phishing attempts.

Step 2 — Narrow the time range. Default is the last 7 days. For incident response, narrow to the specific delivery window.

Step 3 — Analyse delivery actions. Filter by:

Delivery Action	Meaning
Delivered	Email reached the user’s mailbox (may need remediation)
Junked	Moved to Junk Email folder automatically
Blocked	Rejected at the perimeter — never reached the mailbox
Replaced	Attachment replaced by Safe Attachments (Dynamic Delivery)
Quarantined	Held in quarantine — user or admin must release or delete

Step 4 — Open the email entity page. For any suspicious email, click through to see:

Full email headers (sender IP, authentication results, message routing)
URLs contained in the email (with Safe Links click data)
Attachments (with Safe Attachments detonation results)
Similar emails (other messages from the same sender or campaign)

Step 5 — Take remediation action. Select one or more emails and apply:

Remediation Action	What It Does	When to Use
Soft delete	Moves email to the Recoverable Items folder (hidden from user) — recoverable by admins	Standard remediation for phishing that reached mailboxes
Hard delete	Permanently removes email — not recoverable	Severe threats, malware, or when soft delete is insufficient
Move to junk	Moves to Junk Email folder	Borderline emails — spam/bulk that were incorrectly delivered to inbox
Move to inbox	Restores a quarantined or deleted email to inbox	False positive remediation — a legitimate email was incorrectly quarantined

Exam tip: Remediation action permissions

Soft delete and move to junk can be performed by users with the Search and Purge role. Hard delete requires the same role. The default Security Administrator role does NOT include Search and Purge — it must be explicitly assigned. The exam may ask which role is needed to perform email remediation in Threat Explorer.

Automated Investigation and Response (AIR)

AIR extends investigation beyond a single email by automatically correlating related signals and recommending remediation actions.

How AIR triggers

AIR investigations start in two ways:

Automatically — certain alerts trigger AIR (e.g., “A potentially malicious URL click was detected,” “Phish delivered due to an override”)
Manually — an admin selects emails in Threat Explorer and chooses “Trigger investigation”

What AIR does

Expands scope — finds other emails from the same sender, with the same URLs, or matching the same campaign
Correlates signals — checks if users who received the email also showed risky sign-in activity or ran suspicious processes on their endpoints
Recommends actions — proposes remediation (soft-delete all related emails, block the sender, remove forwarding rules set by the attacker)
Executes or awaits approval — depending on your automation level:

Automation Level	Behaviour
Full automation	AIR executes all recommended actions automatically
Semi-automation	AIR executes some actions (low-impact) and queues others for admin approval
No automation	All actions queued for admin approval

Elena runs MedGuard at semi-automation — email remediation runs automatically, but actions affecting user accounts or devices require her approval.

Deep dive: AIR investigation graph

Each AIR investigation produces an investigation graph showing:

Root alert — the trigger that started the investigation
Related entities — users, mailboxes, devices, URLs, and files connected to the threat
Evidence — specific artifacts collected (email headers, file hashes, process trees)
Recommended actions — each with a status (pending approval, completed, failed)
Investigation status — Running, Awaiting action (admin needs to approve), Remediated, Partially remediated, or Failed

The investigation remains in the Action center for 30 days. Admins can review all pending actions, approve or reject them, and see the full chain of evidence supporting each recommendation.

Attack simulation training

Attack simulation training lets you send simulated phishing emails to your own users to measure susceptibility and assign training to those who fall for it.

Payload types

Payload Type	What It Simulates	User Action Measured
Credential harvest	Fake login page that captures username and password	User enters credentials on the fake page
Malware attachment	Email with a harmless file that simulates a malicious attachment	User opens the attachment
Link in attachment	Email with an attachment containing a URL	User opens attachment and clicks the URL
Link to malware	Email with a URL that simulates a malware download	User clicks the URL
Drive-by URL	Email with a URL to a page that auto-executes code (simulated)	User visits the page
OAuth consent grant	Email requesting OAuth app consent	User grants consent to the fake app

Creating a simulation

Elena sets up a quarterly phishing simulation at MedGuard:

Choose a technique — Credential harvest (the most realistic and common real-world attack)
Select a payload — Microsoft provides a library of pre-built payloads, or Elena creates a custom one mimicking a healthcare portal login page
Target users — Elena targets all clinical staff (nurses, doctors, pharmacists) and excludes the security team
Configure landing page — the page users see after clicking the phishing link. It explains that this was a simulation and links to training.
Assign training — users who click the link or enter credentials are automatically assigned training modules (e.g., “How to spot phishing,” “Protecting patient data”)
Set schedule — launch immediately or schedule for a specific date and time
Enable notifications — optional notification to users who complete training

Simulation reporting

Metric	What It Tells You
Compromised rate	Percentage of targeted users who entered credentials or performed the target action
Click rate	Percentage who clicked the simulated phishing link
Report rate	Percentage who reported the email as phishing using the Report Message add-in
Training completion rate	Percentage of assigned users who completed the assigned training modules

Elena tracks these metrics quarterly. MedGuard’s compromised rate dropped from 22% to 8% over three simulation cycles — demonstrating the value of the program to compliance leadership.

Training campaigns

Beyond one-off simulations, you can create ongoing training campaigns that:

Assign training modules to all users (not just those who fail simulations)
Track completion status with due dates
Send automated reminders to users who haven’t completed training
Report completion rates by department, location, or user group

Exam tip: Simulation licensing and roles

Attack simulation training requires Defender for Office 365 Plan 2 (or M365 E5). The Attack Simulation Administrator role is needed to create and manage simulations. The Attack Payload Author role is needed to create custom payloads. These are separate from Security Administrator — the exam may test which role is needed for simulation management vs payload creation.

Restricted entities

When Exchange Online detects that a user account is sending outbound spam or phishing (typically because the account is compromised), it automatically blocks the user from sending further email.

Why users get restricted

Cause	What Happens
Compromised account sending spam	Attacker uses stolen credentials to send bulk spam. Outbound spam filter detects the anomalous sending pattern.
Compromised account sending phishing	Attacker sends phishing emails to external recipients using the compromised account.
Forwarding rule to external address	Attacker creates a mailbox forwarding rule that redirects all incoming email to an external address — outbound filter may trigger on the volume.
Sending limits exceeded	User exceeds Exchange Online sending limits (10,000 recipients per day for cloud mailboxes). Usually indicates compromise, occasionally legitimate mass emailing gone wrong.

Unblocking a restricted user

The restricted user appears in the Defender portal at Email and collaboration > Review > Restricted entities.

Elena’s unblocking process at MedGuard:

Investigate the compromise — check sign-in logs for suspicious activity, review mailbox rules for attacker-created forwarding, check sent items for spam
Remediate the compromise — force password change, revoke active sessions, remove malicious forwarding rules, re-register MFA
Remove the user from Restricted entities — click the user and select “Unblock.” The user can send email again within approximately 1 hour.
Monitor for recurrence — if the user is re-restricted, the compromise wasn’t fully remediated

Deep dive: Restricted connectors

In addition to user accounts, inbound or outbound connectors can also be restricted. If a partner connector is compromised and starts relaying spam through your tenant, Exchange Online blocks the connector. Restricted connectors appear on the same Restricted entities page. Remediation involves fixing the partner’s compromised infrastructure and then unblocking the connector.

The exam may mention connectors in the context of hybrid environments — an on-premises server with a compromised connector could trigger tenant-level sending restrictions if the volume is severe enough.

Restricted entities vs restricted tenant

Scope	What is Blocked	Resolution
Restricted user	A single user account is blocked from sending	Admin unblocks in Restricted entities after remediation
Restricted connector	A specific mail flow connector is blocked	Admin unblocks after fixing the connector configuration
Restricted tenant	The entire tenant is blocked from sending externally	Critical — Microsoft support may need to be involved. Caused by massive outbound spam from multiple accounts

Scenario: Elena responds to a phishing campaign

A wave of phishing emails targeting MedGuard’s clinical staff is detected by Defender for Office 365:

Threat Explorer shows 47 emails with the same sender domain delivered to 35 unique mailboxes over the past 2 hours
Elena selects all 47 emails and triggers soft delete — removing them from user mailboxes
An AIR investigation auto-triggers, expanding the scope to find 12 additional related emails from a slightly different sender address
AIR recommends soft-deleting the 12 additional emails and blocking the sender domain — Elena approves both actions

Elena runs an advanced hunting query to check if any users clicked the URLs in the phishing emails:

EmailUrlInfo
| where Timestamp > ago(4h)
| where Url has "phishing-campaign-domain"
| join kind=inner EmailEvents on NetworkMessageId
| where DeliveryAction == "Delivered"
| project RecipientEmailAddress, Url, Timestamp

Three users clicked the URL. Elena checks their sign-in logs and finds one account showing signs of credential compromise. She forces a password reset and session revocation.
After remediation, Elena schedules an attack simulation using a similar payload to test whether clinical staff can recognise this type of phishing in the future.