Select Two (Multi-Select) Questions

Benign Positive

Benign Positive is a valid top-level classification in Microsoft Sentinel for activity that is confirmed to be real and potentially interesting but not malicious. Examples include a security tool triggered by an authorized penetration test, a misconfigured internal application, or a user performing an unusual but permitted action. Analysts select this classification to document harmless-but-noteworthy alerts separately from actual threats and false alarms.

False Positive

False Positive is a valid incident classification in Microsoft Sentinel used when an alert is determined to be triggered by non-malicious, expected, or otherwise non-indicative activity. This could result from an overly broad analytic rule, a misconfigured connector, or environmental noise. It is distinct from Benign Positive because a false positive typically indicates a rule or logic issue that should be tuned, whereas a benign positive is a real security event that is simply not hostile.

True Positive

True Positive is a valid incident classification in Microsoft Sentinel used when an analyst confirms that an alert accurately identifies malicious or unauthorized activity. It serves as the primary disposition for confirmed security incidents and can be refined with sub-classifications like Malicious or Security Test to preserve details. Marking an incident as True Positive enables appropriate response actions, supports metrics, and helps validate the effectiveness of detection rules.

Block the unapproved cloud storage app

Blocking the unapproved cloud storage app in Microsoft Defender for Cloud Apps immediately enforces a block policy that prevents any session or upload to that app, cutting off the attacker's exfiltration channel. This is a direct containment action that stops ransomware from spreading via file uploads to shadow IT services. By applying a session policy or app governance control, you terminate the active data movement without waiting for user awareness.

Suspend the user's account

Suspending the user's account (disabling it in Microsoft Entra ID) instantly revokes the user's tokens and access rights, preventing the compromised identity from using any Microsoft 365 or Defender-for-Cloud-Apps resources. This neutralizes the attacker's foothold and stops lateral movement or further file encryption. Account suspension is a core containment procedure that limits the blast radius before deeper investigation.

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint is one of the core workloads that compose Microsoft Defender XDR, feeding endpoint detections and alerts into the unified incident queue. Its signals correlate with the other Defender services, making it a required component of the suite.

Microsoft Defender for Identity

Microsoft Defender for Identity is a core Microsoft Defender XDR workload, surfacing identity-based detections from on-premises Active Directory signals. Those alerts correlate into the unified incident queue alongside endpoint, email and cloud app data, making it a required component of the suite.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 is a core Microsoft Defender XDR workload, delivering email and collaboration threat detections. Its alerts correlate with endpoint, identity and cloud app signals in the unified incident queue, making it a required component of the suite.

Include known indicators of compromise from threat feeds

Incorporating threat-feed indicators of compromise lets queries match observed malicious artefacts—IP addresses, domains, file hashes—against telemetry already ingested in Microsoft Sentinel, satisfying the stem's requirement for effective hunting queries. This converts external threat intelligence into concrete detection logic, surfacing known adversary infrastructure without waiting for an alert to fire.

Map queries to MITRE ATT&CK techniques

Mapping queries to MITRE ATT&CK techniques aligns hunts with adversary tactics, satisfying the recommended-practice requirement. It exposes coverage gaps and lets analysts pivot systematically across the kill chain instead of relying on ad hoc searches.

Limit the query to a specific time range

Restricting the query to a defined time range keeps hunting focused and performant, satisfying the stem's requirement for effective Microsoft Sentinel hunting queries. Unbounded searches across months of log data are slow, costly and noisy; scoping to the window of interest surfaces relevant anomalies faster and reduces false positives.

Microsoft Entra ID P2 licenses must be assigned to users.

Microsoft Entra ID P2 licenses are a hard prerequisite for UEBA because Sentinel derives user entity behavior across the identity plane from Microsoft Entra ID Protection, which only emits risk signals and rich user context under a P2 license (e.g., risk detections, risky sign-ins, and user risk history). Without P2, the identity baseline that Sentinel's UEBA machine-learning models rely on is never populated, so user-centric anomaly detection cannot be calculated even though other data sources are connected.

The SecurityInsights solution must be installed in the workspace.

The SecurityInsights solution must be installed in the Log Analytics workspace because it is the solution pack that installs Sentinel as a service, including the UEBA feature, the necessary data connectors, analytics rules, and the Entity Behavior Analytics workspace settings. In the Microsoft Sentinel portal, enabling UEBA is a toggle on the Settings page, and this toggle is only visible and actionable after the SecurityInsights solution has been deployed to the workspace—making it a mandatory two-part condition along with Entra ID P2 licensing.

SecurityEvent (Windows Event Logs)

SecurityEvent carries Windows logon events, including 4624, 4625 and 4648, exposing failed logons, explicit credential use and unusual logon types. These fields let hunters detect anomalous authentication patterns across on-premises and domain-joined systems forwarded to Microsoft Sentinel.

AADNonInteractiveUserSignInLogs

AADNonInteractiveUserSignInLogs captures token issuance and refresh events without interactive user input, exposing anomalies such as impossible travel or suspicious service-principal activity. It satisfies the stem's unusual authentication patterns requirement by surfacing non-interactive sign-ins that interactive-only sources omit, feeding Microsoft Sentinel threat hunting queries.

SigninLogs (Microsoft Entra ID)

SigninLogs records Microsoft Entra ID interactive sign-ins with location, device, risk level and conditional access results. Hunters query it to spot anomalous authentication, such as impossible travel or unfamiliar sign-in properties, satisfying the requirement for authentication-focused hunting data.

Detecting DNS tunneling

Detecting DNS tunnelling is crucial for identifying C2 communication because attackers frequently encapsulate malicious traffic within legitimate DNS queries and responses. Microsoft Sentinel can analyse DNS logs, looking for anomalous patterns such as excessively long domain names, unusual query frequencies, or specific data encoding within DNS records. This technique effectively uncovers covert C2 channels, satisfying the requirement to identify command and control communication.

Analyzing network beaconing patterns

Command-and-control channels frequently use periodic, evenly spaced callbacks, so analysing network beaconing patterns exposes regular intervals and consistent payload sizes typical of implant check-ins. This satisfies the requirement to identify C2 communication through timing regularity rather than content inspection alone.

Examining SSL/TLS certificate anomalies

Self-signed, expired or mismatched certificates on outbound connections often betray malware C2 channels, since adversaries frequently reuse or poorly forge them. Inspecting certificate fields in Sentinel hunting queries surfaces beaconing traffic that domain or IP reputation alone would miss.

Deep understanding of normal network behavior

Baselining normal network behaviour lets hunters spot anomalies such as beaconing, unusual lateral movement or data staging in Defender XDR telemetry. Without knowing what routine traffic looks like, distinguishing genuine malicious activity from benign administrative patterns is impossible, so this underpins every hypothesis.

A clear hypothesis based on threat intelligence

A hypothesis directs hunting rather than aimless querying. Deriving it from threat intelligence about actors targeting your sector focuses advanced hunting queries in Microsoft Defender XDR on specific TTPs, making detection of otherwise invisible activity far more likely within limited analyst time.

Use of MITRE ATT&CK framework

MITRE ATT&CK maps adversary tactics and techniques to concrete hunting queries, ensuring coverage gaps are identified rather than assumed. It gives Microsoft Defender XDR hunters a shared vocabulary and structured progression through the kill chain, preventing over-focus on a single technique.

Block the ransomware file hash using threat intelligence indicators in Microsoft Defender.

Blocking the ransomware executable's SHA-256 hash via Microsoft Defender for Endpoint custom indicators immediately prevents that specific binary from running on any monitored endpoint, independent of signature updates. Because the hash is a known-bad IOC, defining it as a block indicator enforces a deny action at the kernel and network layers, halting execution on already-uninfected devices and stopping the ransomware from propagating through mapped shares.

Initiate device isolation from the Microsoft Defender for Endpoint console.

Initiating device isolation from the Microsoft Defender for Endpoint console severs all inbound and outbound communication from the affected machine (except the MDE cloud service) while leaving the host powered on. This active containment step stops lateral movement, C2 callbacks, and further file-encryption activity, while preserving memory state and event logs for forensic analysis. Isolation is preferred over unplugging the machine because it maintains a managed, monitored channel.

Microsoft Entra ID audit logs

Microsoft Entra ID audit logs are a correct, natively supported data source for Microsoft Sentinel. Sentinel's Microsoft Entra ID connector (formerly Azure AD) ingests sign-in logs, audit logs, and provisioning logs into the workspace for identity-based detection and investigation. This connector is first-party and uses the Microsoft Graph API or diagnostic settings, making it a standard supported source.

AWS CloudTrail

AWS CloudTrail is a correct, natively supported data source for Microsoft Sentinel. The Amazon Web Services connector, which can be configured with an AWS IAM role, collects CloudTrail management and data event logs from an S3 or CloudWatch Logs bucket into Sentinel. This is a first-party, supported integration that enables cloud-account security monitoring.

Windows Security Events

Windows Security Events are natively supported through the 'Windows Security Events via AMA' or legacy 'Windows Security Events' connector, which uses the Log Analytics agent (or Azure Monitor Agent) to collect security event logs from Windows machines. This built-in, first-party connector requires no custom development and is a standard source for detecting threats, making it one of the two correct answers.

Azure Activity Logs

Azure Activity Logs are a native data source via the 'Azure Activity' connector in Microsoft Sentinel, which streams subscription-level events such as resource creation, configuration changes, and service health incidents directly from the Azure platform. This first-party connector is installed with a single click and requires no custom code, so Azure Activity Logs correctly qualify as a natively supported data source.

Report the email as phishing in Microsoft Defender for Office 365

Reporting submits the email to Microsoft for analysis, which updates the threat intelligence and improves automated detection for the whole organization. In MDO, this can be done via the User-reported messages report or the built-in Report Message add-in. This action also allows the security team to investigate the incident and potentially automate remediation policies.

Block the sender's email address or domain

In MDO, you can block the sender by adding to the Tenant Allow/Block List or creating a mail flow rule. Blocking at domain/sender level stops additional emails from the same threat actor from reaching other users. This is a critical containment measure to halt the campaign.

Delete the phishing email from the user's mailbox

Deleting (or purging) the email removes the malicious payload from the mailbox, preventing repeat clicks or accidental interactions. In MDO, you can use the Threat Explorer and mailbox search to find and delete messages across the environment. This is an essential remediation step to ensure the user doesn't return to the email.

The appropriate permissions to run playbooks.

To execute a Logic Apps playbook from an automation rule, Sentinel invokes the Azure Resource Manager trigger using the identity of the user or service principal, which must hold Microsoft.Logic/workflows/triggers/run/action permission, often granted by the Sentinel Responder role. Without those permissions the playbook action is blocked and the automation rule reports a failure. Even if a playbook exists, the rule cannot trigger it unless the required permissions are assigned, so permissions are a required component.

An automation rule with conditions and actions.

The automation rule is the core trigger mechanism because each rule defines the incident states or conditions that start the process and the actions to take, such as changing severity, assigning an owner, or invoking a playbook. With no rule present, there is no logic to match an incident event to a defined workflow, so nothing gets automated. Therefore, an automation rule with both conditions and actions is a required component.

A Microsoft Sentinel workspace.

Automation rules are configuration artifacts stored inside the Log Analytics workspace that has Sentinel enabled, and every incident and action execution is recorded in that workspace. The rule cannot be defined or evaluated outside a Sentinel workspace because the workspace supplies the incident repository, the identity scope for permissions, and the underlying data store for audit logs. Therefore, a Microsoft Sentinel workspace is a foundational requirement.

Incident severity equals High

The condition 'Incident severity equals High' directly implements the SOC's stated requirement to trigger the automation runbook for high-severity incidents. In Microsoft Sentinel, severity is an incident property set during analytics rule detection, and this condition uses the 'equals' operator to match only incidents with the exact severity value 'High'. This ensures the automation workflow engages precisely when the security impact is most significant, without introducing extraneous restrictions.

Incident title contains Phishing

The condition 'Incident title contains Phishing' ensures the automation is specifically scoped to phishing-related incidents, as indicated by a substring match against the incident title. In Sentinel, incident titles are generated from the alert rule's title or description, so containing the term 'Phishing' is a reliable filter for campaigns or payloads that explicitly name the attack type. This condition complements the severity filter by narrowing the automation to relevant threat categories, but it is not a substitute for the severity condition because phishing can occur across multiple severities.

Playbooks (Azure Logic Apps)

Playbooks are cloud workflows built on Azure Logic Apps that you can invoke from Microsoft Sentinel to automate a security response. They can be triggered by an analytics rule (automatically on alert creation) or by an automation rule on an incident, and they support actions such as isolating a compromised host, resetting credentials, opening a ticket, or sending a Teams notification. Because they run with the Sentinel connector's context, playbooks are the native mechanism for incident-triggered orchestration and satisfy the requirement for automated responses.

Automation rules

Automation rules in Microsoft Sentinel allow incident-triggered responses without requiring a separate Logic App, directly satisfying the requirement for automated responses to security incidents. They can run playbooks, change incident status, assign ownership, or add tags based on conditions such as severity or entity type, all natively within the Sentinel workspace. This meets the stem’s constraint of configuring automated responses without external orchestration dependencies.

Configure event grouping or incident grouping by user entity.

In the scheduled analytics rule's "Alert grouping" and "Event grouping" settings, you can define that query results containing the same user entity are combined into a single alert, and later that multiple alerts referencing the same user are combined into one incident. This consolidation directly addresses alert fatigue by collapsing many impossible-travel event pairs into one investigation object centered on the affected user. However, you must consider grouping by other entities like location or IP to avoid over-consolidating distinct attacker activities.

Configure suppression to stop creating new alerts for a defined period after a match.

The rule's "Suppression" setting stops the scheduled query from executing for a defined duration after an alert is generated, preventing the same condition from creating duplicate alerts. While this is an effective way to reduce repeated notifications from a persistent impossible-travel pattern, it is less precise than entity grouping because it completely blinds the rule—even if a new, legitimate sign-in anomaly occurs during the suppression window, no alert will be created. Therefore, suppression should be configured with an appropriate period based on how quickly the SOC expects to investigate.

Set the rule frequency and threshold to trigger when the query returns more than 10 results.

In Microsoft Defender XDR custom detection rules, you must set both the rule frequency (how often the query runs, such as every hour) and the threshold (the number of results that triggers the rule) in the rule's settings. For this scenario, configuring the threshold to fire when the query returns more than 10 results ensures that only significant matches generate alerts, reducing false positives. This step is essential because without a defined frequency and threshold, the rule has no scheduling or triggering condition to act on.

Configure the rule action to generate an alert in Microsoft Defender XDR.

Configuring the rule action to generate an alert is the critical output mechanism of a custom detection rule; when the query results meet the threshold, this action creates an alert that appears in the Microsoft Defender XDR incidents queue. This alert includes metadata like the rule name, affected entities, and the underlying query results, enabling security analysts to investigate and respond. Without this action, the rule would only run silently without producing any actionable security signal.

Save the advanced hunting query as a custom detection rule.

To operationalize an advanced hunting query as an automated detector, you must save it as a custom detection rule from the advanced hunting page by running the query and selecting 'Create detection rule'. This action converts the KQL query into a scheduled rule object that can be assigned a frequency, threshold, alert action, and entity mappings. Without this save operation, the query remains a one-off manual hunt and cannot produce recurring alerts, making this the foundational step in the process.

AADAuditLogs

AADAuditLogs is the correct choice because it is the Microsoft Entra ID audit log that records every directory write operation, including role assignments. Activities such as "Add member to role," "Remove member from role," and PIM role activations are captured here, making it the authoritative table for detecting changes to privileged role membership. A scheduled analytics rule can query this table directly to alert on unexpected or high-risk role assignment events.

IdentityInfo

IdentityInfo is indeed a useful table for contextual enrichment, but it does not store audit events for role assignments. This table contains static identity metadata such as display names, department, job title, and manager, which can be joined to AADAuditLogs to add context to an alert. However, since it lacks historical activity data, it cannot serve as the source for detecting role assignment changes and should be used only for enrichment in a scheduled query.

Microsoft Defender for Endpoint (device events)

Microsoft Defender for Endpoint's device events provide deep host telemetry, including process creation, command lines, network connections, and local account logon events. This enables detection of lateral movement techniques such as PsExec, SMB/WMI remote execution, and RDP sessions at the endpoint level. Because it correlates specific processes with network activity and the originating host, it is a powerful source for hunting lateral movement in Sentinel.

Windows Event Logs (Event ID 5140)

Windows Event Log ID 5140 specifically records network share access, including the sharing machine, target path, and account used. Attackers often use administrative shares like ADMIN$ or C$ during lateral movement, and this event can reveal the source IP address. This log provides direct evidence that a remote account accessed a share, making it a key data source for detecting lateral movement.

Windows Security Events (Event ID 4624)

Windows Security Event ID 4624 is a successful logon event that captures details such as logon type, source workstation, and account name. Lateral movement often involves a compromised account logging on to multiple hosts via network or remote interactive logons, which appear as multiple 4624 events. By correlating these events across multiple systems in Sentinel, an analyst can spot an account hopping between machines, a classic sign of lateral movement.

Configure tenant-wide settings in Microsoft 365

Configuring tenant-wide settings in Microsoft 365 requires the Global Administrator role because these settings affect the entire organization, such as organizational profile, privacy preferences, and integration options. Only Global Administrators have the necessary authorization to modify settings that apply to all users and services across the tenant, ensuring central control and compliance with organizational governance.

Manage roles and administrators in Microsoft Entra ID

Managing roles and administrators in Microsoft Entra ID is a core Global Administrator function because it controls delegation of administrative permissions across the tenant. Only Global Administrators can assign privileged roles like Global Admin, Security Admin, or Compliance Admin to other users. This ensures that the ability to grant or revoke administrative access remains centralized and tightly controlled.