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:

powershellCopyEditpowershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -File "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\PSScript_{676954A7-15C5-45AD-AECB-1E8A46272DFB}.ps1" -ParamsAsBase64 <encoded-base64-text>

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.

---

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

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:

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.