AI and ML Threat Detection in Microsoft Security

Traditional signature-based detection relies on known patterns of malicious activity—like matching a file hash against a database of malware. This approach fails against novel threats, zero-day exploits, and sophisticated adversaries who change tactics. AI and ML threat detection in Microsoft Sentinel addresses this by learning 'normal' behavior from your environment and identifying deviations that indicate compromise. Sentinel uses several built-in ML models that require no manual training—they are pre-trained on Microsoft's vast telemetry from millions of customers and the Microsoft Defender suite. These models are designed to reduce alert fatigue by filtering out noise and surfacing only high-fidelity incidents.

The exam tests your understanding of these models, how they are configured, and when to use them. You must know the difference between Anomaly Detection, Fusion, and Threat Intelligence (TI) mapping, as well as the specific analytics rules that leverage ML.

Sentinel's ML detection operates at multiple layers:

- Anomaly Detection Rules: These are built-in analytics rules under the 'Anomaly' rule template type. Examples include: - "Unusual sign-in" (detects sign-ins from atypical locations, devices, or times) - "Unusual volume of file downloads" - "Unusual number of Azure AD authentication requests" - Each rule has a default frequency (e.g., every 5 minutes) and lookback period (e.g., 14 days for baseline). - The threshold for anomaly score is typically set to 3 (standard deviations above mean), but you can adjust via the rule's 'Anomaly threshold' setting.

To view and enable anomaly rules in the Azure portal:

To verify anomaly detections using KQL:

SecurityAlert
| where AlertName contains "anomaly"
| project TimeGenerated, AlertName, CompromisedEntity, AlertSeverity, ExtendedProperties

To check Fusion incidents:

SecurityIncident
| where ProviderName == "Fusion"
| project TimeGenerated, IncidentNumber, Title, Severity, AlertIds

To inspect UEBA anomalies:

BehaviorAnalytics
| where ActionType == "AnomalousActivity"
| project TimeGenerated, UserPrincipalName, ActivityType, InvestigationPriority

AI/ML detection in Sentinel integrates tightly with:

Scenario 1: Detecting Compromised VIP Accounts

A multinational corporation uses Sentinel to protect C-suite executives. They enable the 'Unusual sign-in' anomaly rule and UEBA. One day, the model detects the CEO's account signing in from a foreign country at 3 AM local time, using a device never seen before. The alert triggers an automated playbook that forces a password reset and notifies the SOC. Without ML, this attack might have been missed because the sign-in was from a legitimate IP range (but not the CEO's typical location). The SOC analyst uses the incident to investigate further and finds that the CEO's credentials were phished. The ML model's baseline adapted over 14 days to learn the CEO's typical sign-in patterns.

Scenario 2: Multi-Stage Attack Detection with Fusion

A healthcare provider uses Sentinel across Azure and on-premises. An attacker performs reconnaissance by scanning for open RDP ports (detected by Defender for Cloud). Then they brute-force an admin account (detected by Azure AD Identity Protection). Finally, they move laterally to a database server (detected by Defender for Identity). Each alert individually might be low severity, but Fusion correlates them into a single incident. The SOC investigates and contains the attack before data exfiltration. Without Fusion, the alerts would be siloed and likely ignored as false positives.

Scenario 3: Threat Intelligence Hunting

A financial institution ingests threat intelligence from multiple open-source feeds (e.g., AlienVault OTX, MISP). They create a custom TI mapping rule to alert on any traffic to known C2 servers. One day, the rule matches an outbound connection from a user's workstation to a malicious IP. The alert includes the TI feed's reputation score and context. The SOC blocks the IP and investigates the workstation, finding a trojan. Without TI mapping, the C2 traffic would blend in with normal internet traffic.

Common Misconfigurations:

What SC-200 Tests:

Common Wrong Answers: 1. "Fusion is a type of analytics rule" – Wrong. Fusion is a correlation engine that operates on alerts from other rules. It is not a rule itself; you cannot create a 'Fusion rule'. 2. "Anomaly rules require a training period before they generate alerts" – Wrong. They use pre-trained models that adapt immediately. However, the baseline improves over time. 3. "TI mapping rules can only use Microsoft-provided feeds" – Wrong. You can bring your own feeds via TAXII, Threat Intelligence Platform, or custom connectors. 4. "UEBA must be enabled manually per workspace" – Wrong. It is enabled by default.

Exam-Tested Numbers:

Edge Cases:

How to Eliminate Wrong Answers:

- Myth: "Fusion detects unknown attacks using ML without any rules." Reality: Fusion correlates alerts from existing rules; it does not generate its own detections.

- Myth: "Anomaly rules must be trained on clean data before use." Reality: They use pre-trained models and adapt to your environment over time; no manual training needed.

- Myth: "TI mapping rules require premium Sentinel tier." Reality: TI mapping is available in all tiers (Free, Standard, Premium) but data ingestion costs apply.

- Myth: "UEBA only works for Azure AD users." Reality: UEBA profiles any entity type, including devices, IPs, and applications.

- Myth: "You can create custom anomaly rules from scratch." Reality: You can only enable/disable built-in anomaly rules or create custom ML models via Azure ML, not define new anomaly logic in Sentinel UI.

- Q: How do I enable Fusion in Sentinel? A: Fusion is enabled by default. To verify, go to Analytics -> Active rules and look for 'Fusion' rule. If disabled, you can enable it by selecting the rule and clicking 'Enable'.

- Q: Can I create a custom anomaly detection rule? A: No, you cannot create custom anomaly rules from scratch in Sentinel. You can only enable/disable built-in anomaly templates. For custom ML, use Azure Machine Learning and deploy via the 'Custom ML' rule template.

- Q: What is the difference between Fusion and UEBA? A: Fusion correlates alerts from multiple sources to detect multi-stage attacks. UEBA profiles entity behavior and identifies anomalous activities. They work together: UEBA alerts can be correlated by Fusion.

- Q: How do I tune an anomaly rule to reduce false positives? A: You can adjust the 'Anomaly threshold' (z-score) in the rule settings. Increasing the threshold reduces alerts. Also, you can set the rule to 'Disabled' if not needed.

- Q: Do I need a license for TI mapping? A: TI mapping itself does not require a separate license beyond Sentinel. However, some TI feeds may be paid. The TAXII connector is free.

- Q: How long does it take for UEBA to build a baseline? A: UEBA starts profiling immediately but the baseline becomes more accurate over time. Microsoft recommends at least 14 days of data for reliable detection.

- Q: Can Fusion correlate alerts from external sources? A: Yes, as long as the alerts are ingested into Sentinel via data connectors and have entity fields (IP, user, host).

- Q: Which of the following is true about Fusion in Microsoft Sentinel? A: Fusion correlates alerts from multiple analytics rules to create multi-stage attack incidents. (Fusion does not generate its own alerts; it uses existing alerts.)

- Q: What is the default lookback period for Fusion correlation? A: 48 hours.

- Q: An administrator wants to detect sign-ins from unusual locations. Which type of analytics rule should they enable? A: Anomaly rule (specifically 'Unusual sign-in'). (Not Fusion, not TI mapping.)

- Q: What is the default threshold for anomaly detection rules? A: A z-score of 3.

- Q: Which data connector is required to use TI mapping? A: A threat intelligence data connector, such as TAXII or Threat Intelligence Platform.

In a global enterprise with 50,000 users, the SOC deploys Sentinel to detect compromised accounts. They enable the 'Unusual sign-in' anomaly rule and UEBA. One day, the model flags a sign-in from a user who typically logs in from New York but now appears from Nigeria using a new device. The alert triggers a playbook that forces a password reset and notifies the user. The SOC investigates and finds that the user's credentials were phished. Without ML, this attack might have been missed because the sign-in used valid credentials. The ML model's baseline adapted over 14 days to learn the user's typical sign-in patterns. The SOC also uses Fusion to correlate this anomaly with a subsequent malware alert from Defender for Endpoint on the same user's device, creating a single incident that speeds up containment.

In another scenario, a healthcare provider uses TI mapping to block known C2 servers. They ingest threat intelligence from a paid feed via TAXII. The mapping rule runs every 5 minutes and alerts on any outbound connection to a malicious IP. One day, the rule fires, and the SOC blocks the IP at the firewall. They investigate the endpoint and find a trojan. The TI feed provided context (malware family, confidence score) that helped prioritize the response. Without TI mapping, the C2 traffic would have blended in with normal internet traffic.

A common misconfiguration is setting the anomaly threshold too low (e.g., z-score 1) to catch more threats, but this generates thousands of false positives daily, overwhelming the SOC. Conversely, setting it too high (z-score 5) misses real attacks. The recommended starting point is the default z-score of 3, then adjust based on feedback. Another pitfall is not enabling Fusion because of fear of missing alerts—Fusion actually reduces noise by grouping related alerts into incidents. In production, Fusion can reduce the number of incidents by up to 90% compared to raw alerts. Performance considerations: Anomaly rules and Fusion are compute-intensive; Sentinel's backend scales automatically, but ingestion quotas apply. TI mapping is lightweight but requires a stable TI feed connection.