Hiding in Plain Sight: A Threat Hunter’s Guide to Abused Ports and Protocols

Your firewall is configured, your perimeter is locked down, and you’re monitoring for suspicious connections. But what about the traffic you expect to see? What if attackers aren’t trying to break down the door, but are simply walking through the one you left open for them?

This is the core challenge behind a common set of adversary tactics: using standard, everyday ports and protocols to conceal malicious activity. By wrapping their communications in traffic that looks legitimate—like HTTP, SMB, or even industrial control protocols—attackers can blend in with the noise, bypassing firewalls and evading detection.

Let’s dive into three related MITRE ATT&CK® techniques—T1071, T0869, and T0885—to understand how adversaries pull this off and, more importantly, how you can build a defensive strategy to catch them in the act.

The Attacker’s Playbook: Why Blend In?

The logic is simple: go where the defenders aren’t looking. Instead of using an obscure port that would immediately trigger an alert, attackers piggyback on services that must be open for business to function.

1. Using Commonly Used Ports (T0885)

This technique is all about exploiting the necessary holes in a network’s defenses. Adversaries know that in both enterprise (IT) and industrial (OT) environments, certain ports are almost always open to allow for essential services. Think about it:

• Port 80/443 (HTTP/HTTPS): Required for web browsing, API calls, and accessing web interfaces on everything from servers to PLCs. Stuxnet famously used Port 80 for its command and control (C2) communications, and attackers in the 2015 Ukraine power grid attack used Port 443.

• Remote Administration Ports: Services like SSH and Telnet are often allowed for system management.

• Industrial Protocol Ports: In OT settings, specific ports for protocols like Tristation CDP (port 1502), used in the Triton malware attack, are expected to be active.

By using these ports, attackers aren’t just trying to get through a firewall; they’re banking on the fact that security teams may not have the resources or technology to inspect the massive volume of traffic flowing through these “allowed” channels.

2. Abusing the Application Layer Protocol (T1071 & T0869)

Taking it a step further, attackers don’t just use the open port—they disguise their traffic as the legitimate protocol that runs on it. This tactic is so fundamental that it appears in both the Enterprise (T1071) and ICS (T0869) ATT&CK matrices.

Adversaries can embed C2 instructions, malware, or exfiltrated data within the structure of common protocols, including:

• HTTP/HTTPS

• SMB

• RDP

• Telnet

• DNS

• Industrial protocols like Modbus, DNP3, and S7comm

We’ve seen this time and time again. WannaCry spread so effectively because it used SMB, a protocol essential for file sharing in many networks. The sophisticated group APT28 used WebRTC for its C2 infrastructure , while groups like Oil Rig and REvil have used standard HTTP POST requests to control their implants in industrial environments.

The line between IT and OT blurs here, as attackers frequently use standard IT protocols to attack OT systems, demonstrating that these techniques are universal threats.

The Defender’s Challenge: Finding the Needle in the Haystack

Detecting malicious activity inside legitimate traffic is incredibly difficult. A simple alert that says “HTTP traffic detected on port 443” is useless. To find the threat, you have to go deeper and understand the one thing attackers can’t easily fake:

A Layered Approach to Detection

Effective defense requires moving beyond high-level metadata and building a nuanced understanding of your environment.

1. Start with Statistical Baselining

Using data from sources like NetFlow or Zeek logs, you can begin to profile your network traffic. Ask questions like:

• How often do these two devices communicate?

• What is the normal amount of data sent between them?

• Is there a predictable pattern to their connections?

This approach can flag anomalies, but on its own, it’s likely to generate low-quality detections without more context.

2. Dig Deeper: The Power of Context

This is where true threat hunting begins. You need to enrich your statistical data with a deep understanding of what is happening inside the protocol.

• Know Your Protocols, Not Just Your Ports: Is the traffic on port 502 actually Modbus? Your IDS might not be able to identify a protocol running on a non-standard port. Some plants even move protocols to different ports as a form of “security by obscurity”. Understand your tools’ capabilities for deep packet inspection and protocol identification.

• Know Your Network’s “Personalities”: Build behavioral baselines for device types and subnets. For example, what does normal traffic from the HR department’s subnet to a database server look like?. If you suddenly see an administrator using SSH from an HR workstation to a sensitive server, that’s a major red flag, even if the protocol itself is allowed.

• Inspect the Details: Attackers often get lazy with the finer points. In HTTPS traffic, are the TLS/SSL certificate fields—like organization name and common name—filled out correctly?. Anomalies here can betray a malicious connection.

• In OT, Focus on Function: Industrial protocols aren’t just streams of data; they perform specific functions. An engineering workstation (EWS) and a human-machine interface (HMI) might both speak the same protocol, but they use it very differently. The HMI might only read data, while the EWS can write new firmware. If you see a function code typically used for programming originating from an HMI, you may be witnessing an attack in progress.

Case Study: The Autonomous Haul Truck

Context is everything. Consider a modern, autonomous mining haul truck—essentially a giant, expensive robot that can “pancake a car”. While analyzing its traffic, you might see web server metadata indicating it’s running on Python. That seems strange for a vehicle. But with deeper investigation, you might find that the truck’s web interface is, in fact, written in Python and is considered normal behavior for that specific component. Without that context, you’d be chasing a false positive. By building a detailed baseline for that asset, you can spot what is truly abnormal.

Three Questions for Your Security Team

Dealing with these techniques is a continuous process of refinement. As you analyze threat intelligence and review your defenses, ask these three questions:

1. Detection: Would our current tools and analytics find this specific threat as it’s described?

2. Tuning: Do we need to update our detection engineering to catch this behavior without drowning our analysts in false positives?

3. Scaling: How do we apply this contextual, behavior-based approach across our entire network?