# Reducing Alert Fatigue: Automating the Triage of Microsoft Defender’s Internal Port Scanning Alerts # **Introduction** Modern security operations rely on **automated alerting** to detect reconnaissance activities within enterprise networks. However, when certain alerts trigger **frequently**, distinguishing between **benign system behavior** and **true security threats** becomes challenging. One such example is the **"Network - Port Scan from Internal IP"** alert, frequently observed in environments with **Microsoft Defender for Endpoint (MDE)** enabled. This alert, designed to detect potential reconnaissance, often flags Defender’s **Standard Discovery Probing** as a potential threat. Without **proper context and automation**, SOC teams may **spend significant time triaging false positives**, leading to alert fatigue and inefficient resource allocation. This article examines how we **investigated and automated the response to Defender-generated scanning alerts** to reduce false positives while maintaining security visibility. # **Alert Summary** * **Event:** Internal system scanning multiple ports on another internal IP * **Source:** `[Internal IP Address]` * **Destination:** `[Internal IP Address]` * **Firewall Status:** All ports are blocked except 443 (HTTPS) and 80 (HTTP). This depends on the configurations of the customers. * **Alert Frequency:** Recurring detections across multiple cases Due to the high frequency of this alert, an investigation was conducted to determine whether it represented a legitimate security concern or expected system behavior. ## **Challenges in Handling Frequent Internal Port Scan Alerts** Despite advanced security tools, organizations face **three key challenges** when handling repeated internal scanning alerts: ### **1\. High Alert Volume with No Immediate Context** Internal scanning alerts typically **lack contextual information** about whether the activity originates from: * **Legitimate security tools** performing asset discovery. * **Compromised endpoints** conducting reconnaissance. * **Unauthorized applications** scanning the network. Without additional metadata, analysts must **manually investigate** each case, leading to **time-consuming reviews and alert fatigue**. ### **2\. Defender’s Built-in Scanning Behavior Triggers False Positives** Microsoft Defender for Endpoint **actively probes networks** to **detect live assets and services**. Unlike attacker-driven scanning, Defender’s **probing is distributed** across all onboarded devices, reducing network footprint but increasing **the number of alerts** generated. Security teams unfamiliar with this behavior may misclassify Defender’s **signed PowerShell scanning scripts** as **potential adversarial reconnaissance**, leading to: * **Frequent false positives** in SIEM systems. * **Unnecessary escalations** to higher-tier analysts. * **Wasted investigative time** on known system behavior. ### **3\. Lack of Automated Correlation & Playbooks for Alert Triage** Many security teams **lack automated detection logic** to differentiate **Defender’s discovery scans** from **actual threats**. Without automation, analysts must: * **Manually query process execution logs** to verify the scanning source. * **Decode encoded command-line parameters** to identify Defender scripts. * **Manually close each false positive alert**, creating operational overhead. To optimize detection, we **designed an automated pre-processing workflow** to handle Defender-related scanning alerts efficiently. ## **Investigating Defender’s Internal Port Scanning Activity** ### **Analyzing the Source of the Alert** During the investigation, we identified an internal host attempting to scan **60 ports on a single destination IP**. The relevant metadata included: * **Source:** `[Internal IP Address]` * **Destination:** `[Internal IP Address]` * **Firewall Status:** All ports are blocked except 443 (HTTPS) and 80 (HTTP). This depends on the configurations of the customers. * **Correlation:** Previous cases were linked to the same destination IP. ### **Tracking the Process Behind the Scan** The first step in the investigation was to **identify the process responsible for initiating these connections**. 1. **Trace the process using its Process ID (PID)** * The alert provided metadata that included a **PID** associated with the network activity. 2. **Check the Parent Process ID (PPID)** * By examining the **PPID**, we aimed to determine whether the scanning process originated from a legitimate security tool or an unknown/malicious source. 3. **Correlate with System Logs** * Cross-referencing with **Windows Event Logs**, **Sysmon**, or **EDR telemetry**, we looked for events tied to **process creation**, **network connections**, and **PowerShell execution**. Using this methodology, we identified a suspicious PowerShell script executing with the following command: ```powershell powershellCopyEditpowershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -File "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\PSScript_{676954A7-15C5-45AD-AECB-1E8A46272DFB}.ps1" -ParamsAsBase64 ``` ### **Decoding the PowerShell Command Parameters** Since the script’s parameters were **Base64-encoded**, the next step was to decode the **Base64 string** to reveal its contents. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1739774664019/b568ce7f-05ba-4d51-b4e5-a52c013fa835.png align="center") --- ### **Verifying Defender’s Official Documentation** Microsoft Defender for Endpoint performs **continuous asset discovery** to map network services and identify unmanaged devices. According to Microsoft: > *"The probing is centrally managed from the cloud to balance the probing attempt between all the supported onboarded devices in the network."* For more details: [Microsoft Documentation](https://learn.microsoft.com/en-us/defender-endpoint/device-discovery-faq) Defender **actively scans for exposed services** using protocols such as: * **ARP, FTP, HTTP, HTTPS, ICMP, RDP, SMB, SSH, Telnet, SNMP, VNC, LDAP, RPC** * These scans **align with normal security hygiene practices** rather than adversarial reconnaissance. Given that the **PowerShell execution path was signed by Microsoft**, the activity was determined to be **benign and non-anomalous**. --- ## **Automating the Detection and Triage Process** ### **Optimized Detection Workflow** To **reduce false positives** and **streamline investigation**, we implemented an **automated pre-processing playbook** with the following logic: 1. **Query Microsoft Defender ATP (WDATP) logs** to extract the command-line execution details. 2. **Decode the PowerShell parameters** to identify scanned IPs. 3. **Check if the destination IP exists in Defender’s scan parameters.** 4. **Automated Response:** * **If the destination IP matches known Defender activity → Automatically close the alert.** * **If the activity does not match known Defender behavior → Escalate to Tier 1 SOC analysts.** **Playbook Diagram:** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1739777948394/b3548f3a-1052-4660-a937-a2c88ceb4a4e.png align="center") ### **Results After Implementation** * False positives were reduced and significantly reducing unnecessary escalations. * Improved analyst efficiency, allowing focus on genuine threats. * Enhanced correlation between Defender activities and SIEM detections. ## **Key Takeaways from the Investigation:** 1. **Understand the Source of Internal Scanning Alerts** * Internal scanning may come from **security tools** rather than adversaries. * Investigate **process lineage (PID/PPID)** to validate scanning origins. 2. **Optimize Security Operations with Automated Triage** * **Automated exclusion rules** prevent unnecessary alerts from Microsoft Defender. * **Pre-processing playbooks** reduce **manual review time** for SOC analysts.