Question 1. Microsoft reports that accounts without MFA are compromised at a rate 99.9% higher than accounts with MFA. What does this mean in practical terms for a 200-user tenant?
MFA guarantees no accounts will be compromised — No. 99.9% reduction is not 100%. AiTM, token theft, and MFA fatigue attacks can still succeed. MFA dramatically reduces risk but doesn't eliminate it.
MFA is only effective against sophisticated attacks — Opposite. MFA is most effective against commodity attacks (password spray, credential stuffing, basic phishing). Sophisticated attacks like AiTM bypass MFA and require additional controls.
For every 1,000 accounts compromised without MFA, only 1 would be compromised with MFA — making MFA the single highest-impact security control available — Correct. The 99.9% reduction means commodity credential attacks essentially don't work against MFA-protected accounts. The remaining 0.1% requires sophisticated, targeted attacks that most organisations rarely face.
MFA is more effective than all other security controls combined — Overstatement. MFA is the highest-impact single control, but defense-in-depth (email protection, device compliance, monitoring) provides protection against the attacks that bypass MFA. No single control is sufficient alone.
Question 2. You're transitioning from security defaults to conditional access. You create a conditional access policy requiring MFA for the "IT Department" group only. What happens to users outside the IT Department?
They continue to be protected by security defaults — No. Security defaults are automatically disabled when conditional access policies are enabled. There is no fallback.
They can sign in with only a password — MFA is no longer enforced for them — Correct. This is the most dangerous mistake when transitioning. Your first conditional access policy must target "All users" (excluding break-glass accounts only) to maintain MFA coverage for everyone. Targeting a single group removes MFA for everyone else.
They're prompted to register for MFA but aren't required to complete it — No. Without security defaults or a conditional access policy targeting them, there is no MFA prompt at all.
Conditional access automatically applies to all users by default — No. Conditional access policies only apply to the users, groups, or roles specified in the policy assignment. They do not have implicit scope.
Question 3. An attacker uses an AiTM proxy to capture a user's fully authenticated session token after the user completes MFA. Which conditional access policy would block the attacker from using the stolen token?
A policy requiring a compliant device (Intune enrolled and meeting compliance standards) — Correct. The attacker replays the token from their own device, which isn't enrolled in your Intune tenant. The conditional access policy checks device identity alongside the token validity. The token is valid but the device is not compliant — access is blocked.
A policy requiring MFA for all users — No. The stolen token already has MFA satisfaction. The policy checks "is MFA completed?" and the answer is yes — the MFA was completed during the original AiTM session. CA001 doesn't help against token replay.
A policy blocking legacy authentication — No. AiTM attacks use modern authentication through a proxy. Legacy auth blocking addresses a different bypass vector (IMAP/POP3), not AiTM.
A policy requiring sign-in from a named location (office IP range) — Partially effective. Location-based policies block sign-ins from outside your defined locations, which would block many AiTM attempts. However, sophisticated attackers use residential proxies in the same country as the victim. Device compliance is a more reliable control because it verifies the device identity, not just the network location.
Question 4. The CFO demands to be exempted from MFA because "it's too inconvenient." What is the correct response?
Exempt the CFO — executives have the authority to accept risk for their own accounts — No. The CFO's account contains the organisation's most sensitive financial data. An exemption makes it the easiest account to compromise and the most damaging if compromised. The risk extends beyond the CFO personally to the entire organisation.
Tell the CFO they have no choice and enforce MFA regardless — Right outcome, wrong approach. Forcing a change without offering an alternative creates conflict. You're more likely to get a directive from the CTO to exempt the account.
Exempt the CFO temporarily while you find a better solution — No. "Temporary" exemptions become permanent. There is no better time to enforce MFA than right now.
Offer a FIDO2 security key as an alternative — a 2-second touch instead of a phone app — and explain the financial risk of an unprotected CFO mailbox in business terms — Correct. Address the convenience concern with a better method (FIDO2 is faster than the Authenticator app), and frame the risk in terms the CFO understands: "Your mailbox is the #1 target for invoice fraud attacks that average £125,000-£500,000 in losses. A 2-second touch on a security key prevents this." Most executive resistance dissolves when you solve the convenience problem and quantify the risk.
Question 5. You discover a compromised account at 09:00 on Monday. The compromise started at 14:00 on Friday — the attacker has had access for 67 hours. What is your first action?
Check the sign-in log to understand the full scope of the compromise before taking any action — No. The attacker has had 67 hours of access. Every minute of investigation before containment extends that window. The sign-in log will still be there after you contain.
Revoke all sessions and reset the password immediately — then investigate — Correct. Contain first: revoke sessions (10 seconds), reset password (30 seconds). The attacker is now locked out. Then investigate: check sign-in log, clean MFA methods, remove inbox rules, revoke OAuth consents. The 15-minute procedure. Evidence is preserved in the logs regardless of containment actions.
Contact the user to ask if they've noticed anything unusual — Not the first action. The user may not have noticed anything — attackers operate silently. And contacting the user doesn't stop the attacker. Contain first, then notify the user.
Escalate to the managed SOC partner — Not yet. The containment actions (revoke + reset) take 2 minutes and are within your capability. Escalation is appropriate after containment if the scope is larger than one account or if the attacker exfiltrated sensitive data.
Question 6. You've reset a compromised user's password and revoked their sessions. The attacker's sign-in attempts now show "Failure" in the log. But 4 hours later, you discover the attacker is still reading the user's email. What persistence mechanism is most likely in use?
The password reset didn't propagate correctly — No. If new sign-in attempts show "Failure," the password reset worked. The issue is a different access path.
The attacker has a backup of the user's mailbox downloaded locally — Possible but this isn't "still reading" — it's reading a static copy. The question specifies ongoing access to current email.
The attacker granted consent to a malicious OAuth application with Mail.Read permissions — app tokens aren't revoked by user session revocation or password reset — Correct. OAuth application tokens are issued to the app, not the user session. Revoking user sessions and resetting the password doesn't affect the app's access token. You must revoke the app consent or delete the enterprise application to stop this access.
The attacker created a mailbox delegate and is accessing through a different account — Possible but less common than OAuth persistence. Check delegate permissions as part of the containment procedure, but OAuth app consent is the more frequent persistence mechanism in modern attacks.
Question 7. Your weekly sign-in log review shows 47 failed sign-ins from a single IP address targeting 23 different user accounts over 6 hours. All failures show "Incorrect password." No successful sign-ins from this IP. What is happening and what should you do?
This is a password spray attack. MFA blocked the attempts because no passwords matched. Verify no accounts use passwords matching the common patterns being sprayed, and consider adding the source IP to a named location block list in conditional access — Correct. A password spray targets many accounts with a few common passwords. The failures confirm that either the passwords didn't match or MFA blocked the successful password matches. Both are good outcomes. Proactive actions: check if any accounts narrowly avoided compromise (correct password but MFA blocked), block the source IP, and remind users about password strength.
This is a brute force attack against 23 accounts — Not quite. Brute force targets one account with many passwords. A spray targets many accounts with few passwords. The distinction matters for response: a spray indicates the attacker is testing commonly reused passwords across your tenant, not targeting a specific user.
Ignore it — all attempts failed so there's no risk — No. Failed attempts today might succeed tomorrow if a user changes their password to one the attacker is spraying. The spray also confirms your tenant is being actively targeted, which increases the urgency of maintaining MFA and monitoring.
Immediately reset passwords for all 23 targeted accounts — Disproportionate. The attacks all failed. Resetting 23 passwords causes significant disruption for no security benefit if the current passwords are strong and MFA is enforced. The appropriate response is monitoring and IP blocking, not mass password resets.
Question 8. Your quarterly report shows: MFA coverage 100%, Secure Score 58% (up from 38%), 142 blocked attacks, 1 incident contained in 12 minutes. Your manager asks: "What's the one thing you need for next quarter?" What do you request?
A SIEM deployment (Microsoft Sentinel) — Too early. Sentinel requires E5 or pay-as-you-go licensing and dedicated time for detection rule management. It's the right tool eventually but not the next priority for an IT admin building security incrementally.
A dedicated security analyst hire — Premature. You've demonstrated that one IT admin can deliver significant security improvement with the existing tools. A security hire makes sense at scale, but the next step is configuring the remaining controls (email, devices) before adding headcount.
An E5 license upgrade for all users — Too expensive and not yet justified. You haven't exhausted the E3 capabilities. Email protection, device compliance, and data protection are all available in E3 and not yet configured.
4 hours per week of dedicated security time to configure email protection and device compliance — the next two phases of the improvement plan — Correct. This is specific, time-bounded, zero-cost (no licensing, no hiring), and directly tied to the improvement plan you've documented. It's also the easiest request for a manager to approve because it's incremental, evidence-based, and the quarterly report proves the previous time investment delivered measurable results.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.
