How do you detect unexpected outbound traffic from DMZ hosts?

Detect it by building a default-deny egress allow-list for each DMZ system and treating every departure as a triage item. List the destinations each host legitimately contacts, such as update mirrors, NTP, approved resolvers and partners, then alert on first-seen external destinations, non-standard ports and regular same-size connections to one host. Add process-level rules for reverse-shell one-liners and tool downloads to /tmp or /dev/shm by the web account. Log both denied and allowed flows, and scope reverse-shell rules to web tier hosts to keep false positives low.

Detecting Unexpected Outbound Traffic from DMZ and Edge Hosts

Exploitation techniques vary, but a compromised edge host eventually has to talk out: to download a tool, to deliver a reverse shell or to beacon to a C2 server (T1571). DMZ and edge systems have a short, knowable list of legitimate destinations, which makes egress the best backstop when every other detection misses. Build the allow-list, log denials and alert on anything outside it.

Signals at a Glance

Signal	Where	ATT&CK
DMZ host connecting to an internet address that is not on its egress allow-list	Firewall, flow, EDR	T1071.001
Outbound connections on non-standard ports or non-HTTP protocol on a web port	Firewall, Zeek, IDS	T1571
bash -i redirected to /dev/tcp, nc -e, or python/perl socket one-liners	auditd, EDR process command lines	T1059.004
curl or wget downloading files to /tmp or /dev/shm from a web account	auditd, EDR	T1105
Regular, same-size connections from a server to a single external host	Flow, Zeek conn.log	T1571
Edge appliance initiating connections to the internal network	Firewall, flow	T1021

Egress Allow-Lists and Alerts

List what each DMZ system legitimately contacts: OS update mirrors, license servers, certificate revocation endpoints, NTP, DNS resolvers, and a handful of business partners. Everything else is denied by default and logged, and every denial from a DMZ host is a triage item. Start with a hunt over existing flow data to build the list:

// Sentinel (KQL) - DMZ hosts connecting to external addresses outside the allow-list
let dmz = dynamic(["192.0.2.0/24"]);          // tune/validate: replace with your DMZ ranges
let allowed = dynamic(["203.0.113.10", "203.0.113.20"]);   // tune/validate: approved destinations
CommonSecurityLog
| where DeviceVendor in~ ("Palo Alto Networks", "Fortinet", "Check Point", "Cisco")
| where ipv4_is_in_any_range(SourceIP, dmz)
| where not(ipv4_is_private(DestinationIP))
| where DestinationIP !in (allowed)
| summarize conns=count(), dports=make_set(DestinationPort, 10), bytes=sum(SentBytes)
    by SourceIP, DestinationIP, bin(TimeGenerated, 1h)
| order by conns desc

Reverse Shells and Tool Downloads

Process telemetry catches the commands that create the egress. Sigma includes rules for the common reverse-shell idioms, and they work well on web tier hosts where interactive shells are unusual:

title: Reverse Shell One-Liner on Web Tier Host
logsource:
  category: process_creation
  product: linux
detection:
  bash_tcp:
    CommandLine|contains|all:
      - 'bash'
      - '/dev/tcp/'
  netcat:
    CommandLine|contains:
      - 'nc -e '
      - 'ncat -e '
      - 'nc.traditional -e '
  script:
    CommandLine|contains|all:
      - 'socket'
      - 'connect'
      - 'subprocess'
  condition: bash_tcp or netcat or script
level: high
# Tune/validate: scope to web tier hosts to keep false positives near zero.

Alert on the first connection from a DMZ host to a new external destination, not only on volume.
Block and alert on outbound DNS from DMZ hosts to anything other than your approved resolvers; it closes a common exfiltration and C2 path.
Record both denied and allowed flows. Denials show the attempt, and allowed flows to unlisted addresses show where the allow-list is incomplete.
Run beacon-timing analysis on DMZ flow data separately from your user network; a quiet server makes periodicity easy to see.

Vetted sources

Use SigmaHQ reverse-shell and download-tool rules, Elastic network and process rules for web server hosts, Splunk ESCU analytics for unusual outbound traffic, and CISA guidance on network segmentation and egress control. Baseline your own environment: patching, license checks and monitoring agents all create outbound traffic that must be allow-listed before alerts are useful.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Egress Allow-Lists and Alerts

Reverse Shells and Tool Downloads

Build Detections That Fire

Edge Device & Web Shell Detection

Detection Hub

Web Server Anomaly Detection

Fortinet Exploitation Detection