Hacktricks-skills echo-service-pentesting

How to identify, test, and document echo services (port 7 TCP/UDP) during network security assessments. Use this skill whenever you're scanning networks, analyzing open ports, or investigating unusual service behavior. Trigger this skill when you see port 7 open, need to verify echo service behavior, want to understand echo service security implications, or are documenting network reconnaissance findings. Don't forget to use this skill even if you're just curious about what an echo service is or how it works.

install
source · Clone the upstream repo
git clone https://github.com/abelrguezr/hacktricks-skills
manifest: skills/network-services-pentesting/7-tcp-udp-pentesting-echo/SKILL.MD
source content

Echo Service Pentesting

A skill for identifying, testing, and documenting echo services during network security assessments.

What is an Echo Service?

An echo service is a simple network protocol that returns any data it receives, unmodified. Originally designed for testing and measurement purposes, echo services listen on port 7 for both TCP and UDP connections.

Why this matters: Echo services are rarely needed in modern networks but are sometimes left running by accident. They can be used for reconnaissance, and in some cases, can be weaponized for denial-of-service attacks.

Security Implications

Denial of Service Risk

⚠️ Critical: Connecting an echo service to another echo service (on the same or different machine) can create a packet amplification loop. This produces an excessively high number of packets and can effectively take machines out of service.

Why this happens: Each echo service responds to every packet it receives. When two echo services are connected, they continuously echo each other's responses, creating an infinite loop of traffic.

Reconnaissance Value

Echo services can be used by attackers to:

  • Verify network connectivity
  • Test firewall rules
  • Confirm host availability
  • Map network topology

Detection Methods

Port Scanning

Echo services typically appear in port scans as:

PORT   STATE SERVICE
7/udp  open  echo
7/tcp  open  echo

What to look for:

  • Port 7 open on TCP or UDP (or both)
  • Service identified as "echo" by nmap or similar tools
  • Unusual response patterns during banner grabbing

Shodan Search

To find echo services on the internet:

port:7 echo

Why use Shodan: This helps you understand if your echo service is exposed to the internet and potentially accessible to attackers.

Testing Echo Services

Contact Echo Service (UDP)

Use netcat to test UDP echo services:

nc -uvn <TARGET_IP> 7

Then type your test message:

Hello echo

Expected response: The service should echo back exactly what you sent:

Hello echo

Contact Echo Service (TCP)

For TCP echo services:

nc <TARGET_IP> 7

Then type your test message and press Enter.

Why test both protocols: Some systems run echo on TCP only, UDP only, or both. Testing both ensures complete coverage.

Automated Testing

For quick verification:

# UDP echo test
echo "test" | nc -uvn <TARGET_IP> 7

# TCP echo test
echo "test" | nc <TARGET_IP> 7

Safety Guidelines

Do NOT Do This

# NEVER connect echo to echo - this creates a DoS loop!
nc -l -u 7 | nc <TARGET_IP> 7

Why this is dangerous: This command connects a local echo listener to a remote echo service, creating an infinite packet loop that can:

  • Consume all available bandwidth
  • Crash the affected systems
  • Impact other network services
  • Potentially violate your authorization scope

Safe Testing Practices

  1. Get authorization first - Only test echo services you're authorized to assess
  2. Use minimal traffic - Send short test messages, not continuous streams
  3. Monitor network impact - Watch for unusual traffic patterns
  4. Document findings - Record what you discover for remediation
  5. Recommend removal - Echo services are rarely needed and should be disabled

Documentation Template

When documenting echo service findings, use this structure:

## Echo Service Finding

**Host:** <IP or hostname>
**Port:** 7/tcp or 7/udp
**Status:** Open/Closed
**Service:** Echo Protocol

**Test Results:**
- UDP echo: [Working/Not Working]
- TCP echo: [Working/Not Working]
- Response time: <latency if measured>

**Risk Assessment:**
- DoS potential: High (if echo-to-echo connection possible)
- Reconnaissance value: Medium
- Internet exposure: [Yes/No]

**Recommendation:**
- Disable echo service if not required
- Block port 7 at firewall if service must remain
- Monitor for unusual echo service usage

**References:**
- [Wikipedia ECHO Protocol](http://en.wikipedia.org/wiki/ECHO_protocol)
- [CERT CA-1996-01 UDP Port DoS Attack](http://www.cert.org/advisories/CA-1996-01.html)
- [Acunetix Echo Service Vulnerability](https://www.acunetix.com/vulnerabilities/web/echo-service-running/)

Remediation Steps

Disable Echo Service

Linux (systemd):

# Stop the service
sudo systemctl stop echo

# Disable from starting on boot
sudo systemctl disable echo

Linux (inetd/xinetd): Comment out or remove the echo service entry in

/etc/inetd.conf
or
/etc/xinetd.d/echo
.

Firewall Blocking:

# Block port 7 at firewall
sudo iptables -A INPUT -p tcp --dport 7 -j DROP
sudo iptables -A INPUT -p udp --dport 7 -j DROP

Why remediate: Echo services provide no legitimate function in most modern environments and pose unnecessary security risks.

Common Questions

"Is this echo service dangerous?"

Echo services themselves aren't inherently malicious, but they:

  • Can be used for DoS attacks (echo-to-echo loops)
  • Provide reconnaissance information to attackers
  • Are rarely needed in modern networks
  • Should be disabled unless there's a specific requirement

"How do I know if it's actually an echo service?"

Test it by sending data and checking if you get the exact same data back. If the response matches your input exactly, it's likely an echo service.

"Can I use echo services for legitimate purposes?"

Historically, echo services were used for:

  • Network latency testing
  • Connectivity verification
  • Protocol debugging

Modern alternatives (ping, traceroute, specialized monitoring tools) are safer and more appropriate.

References