Respond to security incidents practice questions

Real-time detections (Plan 1) and Threat Explorer (Plan 2) share views, but Threat Explorer adds more.

Threat Explorer has every capability of Real-time detections plus more views, filters and actions. The URL clicks and Campaigns views exist only in Threat Explorer, and Real-time detections shows detections at delivery time only, not post-delivery activity such as clicks. Threat Explorer requires Defender for Office 365 Plan 2.

1. Identify the data needed: post-delivery clicks and campaigns.
2. Recall which tool has the URL clicks and Campaigns views.
3. Map the tool to its license: Threat Explorer = Plan 2.

Exam tip: Clicks, campaigns and post-delivery activity live in Threat Explorer, which needs Defender for Office 365 Plan 2.

Admin submissions can create Tenant Allow/Block List block entries with a chosen lifetime.

When you submit a message as 'Should have been blocked', you can select 'Block all emails from this sender or domain', which creates a block entry in the Tenant Allow/Block List. 'Remove block entry after' defaults to 30 days and also offers Never expire or a specific date of up to 30 days. Only Never expire keeps the block until someone removes it, and a domain block (not a URL block) covers every message from the domain.

1. Pick the submission type: should have been blocked.
2. Pick what to block: the sender's domain, not the URL.
3. Pick the lifetime: the default is 30 days, so choose Never expire.

Exam tip: Block from a submission: the entry defaults to 30 days; choose Never expire for a block that stays until removed.

Impersonation false positives are fixed in the anti-phishing policy that detected them.

Microsoft notes that submitting a message as should not have been blocked doesn't automatically override impersonation protection in the tenant. For a recurring legitimate sender flagged by user or domain impersonation, you update Trusted senders and domains in the anti-phishing policy that detected the message (an allow entry in the Tenant Allow/Block List is the other documented route). Spoof allows cover a different verdict, and removing the CFO from protection breaks the stated requirement.

1. Name the detection: user impersonation protection, not spoof or spam.
2. Recall that a false-positive submission doesn't by itself override impersonation protection.
3. Keep the CFO protected: don't shrink the users to protect list.
4. Trust the partner in the policy that detected the messages.

Exam tip: Recurring impersonation false positive: trust the sender in that anti-phishing policy; resubmitting doesn't override impersonation.

Accounts that exceed outbound sending limits are restricted and listed on the Restricted entities page.

When a mailbox exceeds the service or outbound spam policy limits, it can still receive mail but can't send, it's added to the Restricted entities page, and its messages bounce with 5.1.8. Once the account is secured, an admin removes the restriction with Unblock on that page (or Remove-BlockedSenderAddress in Exchange Online PowerShell).

1. Read the 5.1.8 bounce as an outbound sending restriction.
2. Confirm the account is secured first.
3. Remove the user from the Restricted entities page.

Exam tip: Bounces with 5.1.8 after spam: secure the account, then Unblock it on Restricted entities (or Remove-BlockedSenderAddress).

A password reset alone doesn't end every form of access an attacker may have.

Microsoft's response steps for a compromised account include revoking active sessions, which invalidates refresh tokens issued before the reset, and replacing app passwords, which a password reset doesn't revoke. Restricted entities, risk dismissal and auditing all address other problems.

1. Ask what remains valid after a password change.
2. Sessions/refresh tokens and app passwords both do.
3. Discard actions that only restore function or record activity.

Exam tip: After a password reset, still revoke sessions and replace app passwords.

The Defender portal marks incidents where attack disruption acted with visual cues.

When automatic attack disruption acts, the incident queue shows an Attack Disruption tag beside the incident, and the incident page shows the tag, a yellow banner describing the action, and contained assets in the incident graph. The '(attack disruption)' string is appended to titles via the API for high-confidence incidents likely to be disrupted, so it's not the portal's record of containment.

1. Recall how the portal marks disruption: tag, banner, asset status.
2. Separate the API title suffix from the portal tag.
3. Filter the incident queue on the tag.

Exam tip: Find disrupted incidents by the Attack Disruption tag; the '(attack disruption)' title suffix is an API signal.