Isolate suspicious communications: KQL for ports 4444 and 8080

In the defense-in-depth model, monitoring what comes into your network is crucial, but monitoring what comes out is vital. When malware or ransomware manages to run on a machine (often via a phishing email), its top priority is to “call home.” It must establish communication with a Command and Control (C2) server managed by the attacker to download its final payload or exfiltrate stolen data.

To bypass basic firewalls, attackers often use non-standard network ports or those linked to development tools. For a SOC analyst, track communications to these high-risk ports via the tableDeviceNetworkEventsis a daily Threat Hunting mission.

Why target ports 4444, 8000, 8080 and 9000?

Legitimate business traffic typically uses ports 80 (HTTP) and 443 (HTTPS) for web browsing. However, attackers like to use alternative ports to go under the radar or because they use offensive tools configured by default on these channels:

• Port 4444:This is the default listening port for the popular Metasploit (Meterpreter) hacking framework. The presence of outgoing communication on this port is an absolute Red Flag indicating that an attacker has taken remote control (Reverse Shell) of a computer.
• Ports 8000, 8080, 9000:Often used by test web servers (Python, Node.js, Tomcat), attackers frequently hijack them to host malicious scripts or bypass strict HTTP filtering rules on port 80.

The network discovery KQL query (DeviceNetworkEvents)

The tableDeviceNetworkEventsMicrosoft Defender for Endpoint logs every network connection creation (TCP/UDP) on monitored devices.

Here is the KQL query template to instantly isolate machines attempting to communicate to these high-risk ports:

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where ActionType == "ConnectionSuccess"
| where RemotePort in (4444, 8000, 8080, 9000)
// Exclure les IP privées internes pour ne garder que le trafic sortant vers Internet
| where RemoteIPType == "Public"
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl
| sort by Timestamp desc

Analysis of the query:

1. The outgoing focus (RemotePortAndRemoteIPType):We explicitly look for successful connections outside the network on the list of suspicious ports.
2. Process identification (InitiatingProcessFileName):The most valuable information! Knowing that the computer connected to port 4444 is fine, but knowing that it is the processpowershell.exeOrwscript.exewho initiated the connection is definitive proof of a Fileless compromise.

MSSP automation with Akuity SOC

Deploying this network monitoring to 50 different enterprise customers through the Azure portal is a tedious task that often discourages MSSPs.

This is why the orchestratorAkuity SOCturns this routine into one click. The Threat Hunting KQL (Kusto Query Language) terminal includes a ready-to-use template called“Suspicious network”.

Using the platform's Multi-Tenant Selector, the L1 analyst can load this template and scan each client's network security at lightning speed. Results are displayed asynchronously in a dynamic grid.

Transform the alert into remediation

If the query reveals that an accounting PC is communicating continuously on port 4444 to an IP address in Russia:

1. The analyst evaluates the reputation of the destination IP address (RemoteIP) via Akuity's built-in AlienVault OTX gauge.
2. The IP is qualified as a C2 server by Gemini AI ratings.
3. The analyst triggers a containment SOAR action: heisolate the network machinevia Microsoft Intune in one click, stopping data exfiltration instantly, after validating the action with its MFA code (TOTP).

Block clandestine communications in real time.> Experiment with our network analysis templates using ourThreat Hunting Centralized KQL for MSSPand reduce incident response time.