Reducing Alert Fatigue: Automating the Triage of Microsoft Defender’s Internal Port Scanning Alerts

Search for a command to run...

No comments yet. Be the first to comment.
I. Introduction Coolify is an open-source, self-hostable PaaS that lets you deploy apps, databases, and pre-baked services on your own servers — the "Vercel/Heroku/Netlify replacement, but you own the

I. Introduction Kestra is an open-source event-driven workflow orchestration platform written in Java on top of Micronaut. It lets teams declare "flows" — task graphs that move data, call APIs, run sc

Disclosure status: Reported to vendor and coordinated through a private fix path. I. Introduction Warp is an agentic development environment, born out of the terminal. Use Warp's built-in coding agent
![[CVE-2026-48731] AI-Assisted Discovery of Command Injection in Warp Terminal](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F699fec8cc9015c37f6e5364f%2Fe7817cef-a8af-45ec-b931-4e08225edeb6.png&w=3840&q=75)
Author: Anhlt91, Thuanhn Date: May 2026Tags: AI Claude Bug Hunting Closed-Source Security Research Overview I used Claude AI to find real security vulnerabilities in a closed-source enterprise produc
I. Introduction Filament is an open-source full-stack UI framework for Laravel built on top of Livewire. It lets developers compose admin panels, forms, tables, infolists, actions, and notifications a

Night-Wolf Team
58 posts
FPT Cyber Security Assurance Service
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.
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.
Despite advanced security tools, organizations face three key challenges when handling repeated internal scanning alerts:
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.
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.
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.
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.
The first step in the investigation was to identify the process responsible for initiating these connections.
Trace the process using its Process ID (PID)
Check the Parent Process ID (PPID)
Correlate with System Logs
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>
Since the script’s parameters were Base64-encoded, the next step was to decode the Base64 string to reveal its contents.

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.
To reduce false positives and streamline investigation, we implemented an automated pre-processing playbook with the following logic:
Query Microsoft Defender ATP (WDATP) logs to extract the command-line execution details.
Decode the PowerShell parameters to identify scanned IPs.
Check if the destination IP exists in Defender’s scan parameters.
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:

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.
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.
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.