AD0.2 What Attackers Target in M365

The attack chain you need to understand

Forget network diagrams and firewall rules. The attack chain that hits M365 tenants is simpler, faster, and harder to detect than a traditional network breach. It works like this: the attacker sends a phishing email that contains a link to a fake Microsoft login page. The user clicks the link, sees a familiar login screen, enters their username and password, and completes MFA if it’s enabled. The attacker — who is running a reverse proxy between the user and Microsoft’s real login page — captures the session token. Within seconds, the attacker has a valid, MFA-authenticated session to the user’s M365 account.

From there, the attacker is a legitimate authenticated user. They can read email, download files from SharePoint, search Teams, and create inbox rules that forward future emails to an external address. If the user is a finance team member, the attacker reads email conversations about pending payments, learns the tone and style of internal communication, and then sends a carefully crafted email — from the compromised account — redirecting a legitimate payment to the attacker’s bank account. The user’s colleagues trust the email because it came from a real internal account. By the time anyone notices, the money is gone.

This is not a theoretical scenario. It’s the most common attack chain against M365 environments in 2025-2026, and it succeeds because the default M365 configuration has no defense against it. Default security doesn’t include conditional access policies that check device compliance or sign-in risk. Default email protection doesn’t block the phishing link if it’s hosted on a newly registered domain. Default monitoring doesn’t alert on the attacker’s sign-in from an unusual location because nobody is watching the sign-in logs.

Why the network perimeter doesn’t protect you

If you’ve spent your career thinking about security in terms of networks — internal vs external, trusted vs untrusted, inside the firewall vs outside — M365 breaks that model entirely. Your M365 tenant is accessible from any device, on any network, from any location in the world. The “perimeter” is the login page. The only thing between an attacker and your organisation’s data is the authentication mechanism — and if that mechanism is just a username and password, you don’t have a perimeter at all.

This is why identity is the critical control. MFA adds a second factor that the attacker must overcome. Conditional access adds conditions — device compliance, location, risk level — that the attacker must meet. Together, they build a perimeter around your identity layer that replaces the network perimeter you no longer control. An attacker with a phished password but no registered MFA method can’t authenticate. An attacker who passes MFA but triggers a high-risk sign-in detection gets blocked by conditional access. An attacker who authenticates from an unmanaged device gets restricted to browser-only access with no download capability.

None of this happens with default configuration. You have to build it. That’s what the next module teaches.

The BEC problem: when email becomes a weapon

Business email compromise is the most financially damaging attack type in M365 environments. It doesn’t require malware, doesn’t require technical exploitation, and doesn’t trigger most security alerts. The attacker compromises a mailbox (usually through credential phishing), sits quietly reading email for days or weeks, identifies financial transactions in progress, and then — at the perfect moment — sends an email from the compromised internal account instructing someone to change payment details.

The damage from a single successful BEC attack typically ranges from tens of thousands to millions of pounds. And the attack succeeds because the email comes from a trusted internal account, references a real transaction the recipient already knows about, and arrives at a time when the recipient is expecting communication about the payment. There’s no malware for the antivirus to catch, no suspicious link for the email filter to block, and no unusual network traffic for the firewall to flag.

The defenses against BEC are all inside M365: MFA to prevent the initial account compromise, inbox rule monitoring to detect attacker-created forwarding rules, sign-in log analysis to identify anomalous access patterns, and user awareness to recognise out-of-band payment change requests. These are the controls this course teaches you to configure and monitor.

What a real attack looks like in the logs

Understanding the theory is one thing. Recognising the evidence is another. Here’s what a credential phishing attack looks like in the Entra ID sign-in log — the actual fields you’ll check when investigating.

The legitimate user signs in at 09:15 from IP 203.0.113.45 (your office network), with a client app of “Browser” and a status of “Success.” This is normal. Then at 14:32, the same account signs in from IP 198.51.100.22 (an IP in another country), with a client app of “Browser,” status “Success,” and MFA satisfied by claim — meaning the session token already had MFA completed. The location is different, the IP is different, but the sign-in succeeded because the attacker captured a fully authenticated session token through the AiTM proxy.

Within minutes of the 14:32 sign-in, the audit log shows “New-InboxRule” — the attacker created a rule that forwards emails containing “payment,” “invoice,” or “bank” to an external address. This rule operates silently. The user doesn’t see it unless they navigate to Outlook → Settings → Rules. Most users never check.

The pattern is always the same: legitimate sign-in from a known IP, then a second sign-in from an unknown IP within hours, followed by configuration changes (inbox rules, MFA method registration, or mailbox delegation). Once you know what the pattern looks like, you will recognise it instantly in the sign-in logs. You can find this evidence right now in your own tenant. Navigate to entra.microsoft.com → Monitoring → Sign-in logs. Filter by a specific user and look at the “IP address” and “Location” columns. Any sign-in from a location where the user isn’t physically present warrants investigation. Module AD1.8 teaches you to do this systematically.

Mapping attacks to controls

Every attack against your M365 tenant follows the same pattern: gain access (identity), deliver the attack (email), achieve the objective (data). The security controls you’ll configure in this course map directly to each phase.

For identity attacks, MFA and conditional access are the primary defense. Module AD1 covers this in full — deploying MFA, building your first three conditional access policies, and handling the exceptions that every organisation has. Identity is the highest-impact control because it stops the attacker before they can do anything else.

For email attacks, Defender for Office 365 is the primary defense. Module AD2 covers anti-phishing policies, Safe Links, Safe Attachments, and email authentication (SPF, DKIM, DMARC). Email protection is the second-highest priority because email is the delivery mechanism for 90%+ of attacks that target M365 users.

For data protection, sensitivity labels and DLP policies limit what an attacker can do even if they get in. Module AD5 covers the basics of data protection — not at the enterprise level, but at the IT administrator level where the goal is to prevent the most damaging data leaks without building a full data governance programme.

The order matters: identity first, email second, data third. An attacker who can’t authenticate can’t read email. An attacker whose phishing email doesn’t land can’t steal credentials. Data protection is the last line of defense, not the first.