NetworkListenIP4: CrowdStrike Listening Socket Event and Queries

What it records

NetworkListenIP4 is written when a program on a host puts a socket into listening mode — when it starts waiting for incoming IPv4 connections. The record holds the LocalAddressIP4 and LocalPort it listens on and the Protocol (6 TCP, 17 UDP). ConnectionFlags marks raw sockets (1) and the promiscuous modes (2, 4 and 8) used to capture traffic. Panther documents listening and connecting events with closely related schemas, which is why remote-address fields also appear in the field list; for a listener they say little.

ContextProcessId names the listening process: it is that process’s TargetProcessId in ProcessRollup2. CrowdStrike’s published query for programs bound to low ports joins the two events on exactly these fields, keeps ports below 1024 and leaves out 127.x addresses. Once a connection is actually accepted, NetworkReceiveAcceptIP4 is the event name CrowdStrike’s queries use for it; outgoing connections are NetworkConnectIP4.

When it matters

A listener is a door. Most are expected — web servers, database servers, management agents — which is why the useful question is which ones are new or rare:

• Backdoors and bind shells. A shell, script host or unknown program listening on any port, or a program from a user or temporary folder opening a listener, is the classic shape of a backdoor.
• Unexpected remote access. VNC on 5900, an RDP listener on a host where remote desktop should be off, or remote-management agents nobody approved.
• Low ports bound by ordinary programs. Ports below 1024 normally belong to known services; CrowdStrike publishes a query for exactly this check, and a Windows one for listeners below port 10,000.
• Traffic capture. A listener with promiscuous-mode ConnectionFlags set on a host that is not a network sensor.

How to investigate

1. List listeners by LocalPort and Protocol across the estate and sort by how few hosts have each; the rare ones come first.
2. Name the program behind each rare listener by joining to ProcessRollup2 on the process ID, and note its path and command line.
3. Check whether anything connected: look for accepted connections on that port, and at firewall rules that expose it.
4. On Linux servers, compare listeners with what the host is supposed to run.

Programs listening on ports below 1024, following CrowdStrike’s published query:

#event_simpleName=ProcessRollup2
| join({#event_simpleName=NetworkListenIP4 LocalPort<1024 LocalPort!=0}, field=TargetProcessId, key=ContextProcessId, include=[LocalAddressIP4, LocalPort], limit=200000)
| LocalAddressIP4!=/^127\./
| groupBy([aid, ComputerName, ImageFileName, LocalAddressIP4, LocalPort], limit=max)

Listening ports by how many hosts have them — the rarest first:

#event_simpleName=NetworkListenIP4
| LocalAddressIP4!=/^127\./
| groupBy([LocalPort, Protocol], function=count(aid, distinct=true, as=Hosts), limit=max)
| sort(Hosts, order=asc, limit=200)

Low-port listeners over Falcon Data Replicator data in Splunk (add your index):

sourcetype="crowdstrike:events:sensor" event_simpleName=NetworkListenIP4 LocalPort<1024
| where NOT like(LocalAddressIP4, "127.%")
| stats dc(aid) AS Hosts, values(LocalAddressIP4) AS Addresses by LocalPort, Protocol
| sort Hosts

The CrowdStrike field reference covers the export format, and the free log analyzer reads Falcon exports in the browser.