Web server internal service connection
A web-server worker process opened a connection to a remote-administration or file-sharing service.
What it detects
A web-server worker process opened a connection to a remote-administration or file-sharing service. A web server answers HTTP; it has no reason to speak RDP, SMB, WinRM or SSH. When it does, the near-certain explanation is a WEBSHELL being used to tunnel traffic — the operator posts to a script on the site, and the web process relays the connection inward.
This is how Tunna and reGeorg work, and it is a strong signal for two reasons: the tunnel is indistinguishable from ordinary web traffic on the wire, and the connections often target 127.0.0.1 — a loopback connection never crosses the network, so no perimeter or network sensor can see it. The endpoint's own process telemetry is the only place this is visible.
MITRE ATT&CK mapping
False positives and triage
Two genuine cases exist. A web application legitimately talking to a database will hit 1433 or 3306 — if that is normal for this site, exclude those two ports here rather than disabling the rule. And node.exe is a general-purpose runtime, not only a web server, so it carries more benign traffic than the others.
RDP, SMB and WinRM have no benign explanation from a web worker. To confirm: check whether a file was recently written into the site's content directory — that is the webshell, and it is the artefact to recover. Then look at what the destination is: 127.0.0.1:3389 means the operator is reaching this host's own desktop through the web server, and an internal address means they are pivoting deeper.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 85%. Source: rules/windows/web_server_internal_service_connection.yaml, licensed under the Apache License 2.0.
id: windows.c2.web_server_internal_service_connection
version: 1.0.0
status: stable
severity: critical
confidence: 0.85
platforms: [windows]
mitre_techniques: [T1572, T1505.003]
description: |
A web-server worker process opened a connection to a remote-administration or
file-sharing service. A web server answers HTTP; it has no reason to speak RDP,
SMB, WinRM or SSH. When it does, the near-certain explanation is a WEBSHELL being
used to tunnel traffic — the operator posts to a script on the site, and the web
process relays the connection inward.
This is how Tunna and reGeorg work, and it is a strong signal for two reasons:
the tunnel is indistinguishable from ordinary web traffic on the wire, and the
connections often target `127.0.0.1` — a loopback connection never crosses the
network, so no perimeter or network sensor can see it. The endpoint's own process
telemetry is the only place this is visible.
match:
process_name_any:
- w3wp.exe
- httpd.exe
- nginx.exe
- php-cgi.exe
- tomcat.exe
- node.exe
destination_port_any: ['3389', '445', '5985', '5986', '22', '135', '1433', '3306']
correlation_keys: [hostname, destination_ip]
false_positive_guidance: |
Two genuine cases exist. A web application legitimately talking to a database will
hit 1433 or 3306 — if that is normal for this site, exclude those two ports here
rather than disabling the rule. And `node.exe` is a general-purpose runtime, not
only a web server, so it carries more benign traffic than the others.
RDP, SMB and WinRM have no benign explanation from a web worker. To confirm: check
whether a file was recently written into the site's content directory — that is the
webshell, and it is the artefact to recover. Then look at what the destination is:
`127.0.0.1:3389` means the operator is reaching this host's own desktop through
the web server, and an internal address means they are pivoting deeper.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.