Protocols Attackers Abuse

HTTP and HTTPS for Payload Delivery and C2

HTTP and HTTPS are the most abused protocols on the internet simply because of volume. Every network allows outbound web traffic, and most proxies and firewalls are tuned to let it flow with minimal friction. TLS encryption compounds this: a growing share of that traffic cannot be inspected for content at all without a break-and-inspect proxy.

Attackers exploit this on two fronts: getting malware onto a host in the first place, and then talking to that malware once it is there.

Payload Delivery

Delivery over HTTP takes two common forms.

• Drive-by downloads. Malicious content is served from a compromised or attacker-controlled website, often through a browser exploit or a fake update prompt, with no action needed from the victim beyond visiting the page.
• Staged payloads. A small first-stage loader, often delivered through phishing, reaches out over HTTP to fetch a second-stage payload from an attacker server. Splitting delivery into stages lets the attacker keep the initial lure small and unremarkable while holding the more detectable capability back until after the victim has already executed something.

Command and Control

Command and control over HTTP/S works because C2 frameworks deliberately mimic legitimate web traffic. A beacon checks in to a C2 server at intervals, requesting tasking and posting back results, formatted to resemble ordinary API calls or browser requests. Frameworks like Cobalt Strike default to HTTP/S beaconing precisely because it blends with the baseline.

The C2 channel does not need to look suspicious on its own; it needs to look like nothing at all, one more request among thousands.

Detection Tells

• User-agent strings. A beacon that claims to be a specific browser version but omits the headers, cookies, and referer chains a real browser generates stands out once you know to look. Outdated or generic user-agent strings, requests with no accompanying DNS lookup for the destination hostname, and traffic to a domain with no legitimate business reason to be contacted are all signals worth correlating.
• Beaconing interval. Legitimate application traffic tends to be bursty and tied to human activity or scheduled jobs with predictable timing. C2 beacons, even ones that jitter their timing to avoid pattern detection, tend to check in with a rough periodicity over long stretches of time. Plotting connection timestamps to a given external host and looking for a near-constant interval, even a jittered one, is one of the more reliable ways to surface a beacon that has blended into normal traffic volume.

SMB for Lateral Movement

Server Message Block (SMB) is the protocol behind Windows file and printer sharing. It is also one of the most heavily abused protocols for moving between hosts inside a compromised network.

Once an attacker has valid credentials or a foothold with sufficient privileges, SMB gives them a built-in, expected way to read, write, and execute on other machines without introducing any new tooling that would stand out.

Abuse Patterns

• Administrative shares. Windows automatically exposes hidden shares like C$ and ADMIN$ on every machine, mapping to the root of the C: drive and the Windows directory respectively, accessible to any account with local administrator rights. An attacker who has compromised a domain account with admin privileges on other hosts can connect to these shares directly, drop a binary or script onto a remote machine, and then trigger execution through a separate mechanism such as a scheduled task or a service.
• PsExec-style remote execution. The legitimate Sysinternals tool PsExec, and the many attacker reimplementations of the same technique, copy an executable to ADMIN$ over SMB, then use the Service Control Manager over the same authenticated session to create and start a temporary service that runs the payload. The result is code execution on a remote host using nothing but standard SMB and RPC traffic and credentials the attacker already controls. Because the mechanism is identical to what legitimate IT administration tools use, distinguishing malicious movement from a sysadmin pushing a software update comes down to context: which account is doing it, at what hour, against how many hosts, and whether that account has a documented reason to be an admin session initiator at all.
• EternalBlue. This is the historical case where SMB itself, not just its administrative use, became the attack surface. The vulnerability, in the SMBv1 implementation of Windows, allowed unauthenticated remote code execution and was weaponized at massive scale in the WannaCry and NotPetya outbreaks of 2017. SMB abuse is not limited to credential-based lateral movement; the protocol implementation itself has had critical, wormable flaws, and SMBv1 in particular should not exist on a modern network.

Detecting SMB Lateral Movement

Detecting SMB-based lateral movement generally means watching for the pattern rather than the protocol. Watch for a single account authenticating to ADMIN$ or C$ on a series of hosts in a short window, unusual process creation tied to a service that was just installed remotely, or SMB traffic between workstation-to-workstation pairs that have no business reason to talk to each other at all. Most legitimate SMB traffic in a well-segmented network flows to file servers, not laterally between endpoints.

RDP for Remote Access

Remote Desktop Protocol (RDP) gives a user a full interactive graphical session on a remote Windows machine. It is used legitimately every day by IT support staff, remote workers, and system administrators managing servers that are not physically in front of them.

That same full interactive access is exactly what makes RDP valuable to an attacker who has obtained or guessed a working set of credentials.

Abuse Patterns

• Brute forcing and password spraying. Credential attacks against internet-exposed RDP are one of the most common initial access vectors seen in ransomware intrusions. Automated tools sweep IP ranges for hosts with port 3389 open, then either hammer a small set of usernames with large password lists (brute forcing) or try one or two common passwords across a large set of usernames (spraying, which avoids account lockouts by staying under the threshold for any single account). Once valid credentials are found, the attacker has an interactive foothold that looks, from the server's perspective, identical to any other remote logon.
• Persistence and lateral movement. After initial compromise, RDP is frequently reused as both a persistence mechanism and a lateral movement tool. An attacker who has already gained a foothold through another vector will often enable RDP on additional internal hosts, create a new local account, or add an existing account to the Remote Desktop Users group, giving themselves a durable way back in that survives the loss of the original access point. RDP sessions between internal hosts, particularly from a workstation to a server or between workstations with no administrative relationship, are a strong lateral movement indicator worth building detections around.
• BlueKeep. This is the RDP equivalent of EternalBlue as a historical reference point: a 2019 vulnerability in RDP's implementation on older Windows versions that allowed unauthenticated remote code execution, wormable in the same way EternalBlue was, though it was never weaponized at the same scale in the wild before patches and mitigations became widespread. RDP abuse is not limited to credential attacks; the protocol has carried critical, pre-authentication flaws of its own.

Detecting RDP Abuse

Detection for RDP abuse centers on the same reasoning as SMB: know what normal RDP usage looks like for your environment, then flag departures from it. Successful logons following a burst of failures from the same source, RDP sessions originating from unexpected geographic locations or from Tor exit nodes, logons to servers from accounts that have never logged onto that host before, and new local accounts appearing shortly before RDP activity from those accounts are all high-value signals.

DNS Tunneling in Depth

DNS tunneling deserves a deeper look than a general introduction can give it, because the mechanics explain why it remains effective even in security-mature environments. DNS resolution is treated as infrastructure rather than as application traffic in most organizations.

Firewalls that block nearly everything else outbound routinely leave UDP/TCP port 53 wide open, because blocking it breaks name resolution for the entire network. Tunneling tools exploit exactly that gap.

How the Tunnel Works

1. The attacker controls the authoritative DNS server for a domain they own, so any query for a subdomain under that domain ultimately reaches infrastructure they control.
2. Data is encoded. Data to be exfiltrated, or C2 tasking to be delivered, is encoded, commonly using Base32 or Base64 variants that survive DNS's restricted character set.
3. Data is split into subdomain labels small enough to fit as hostname components, something like 7xkq9f2mZ.data.evil-domain.com.
4. The infected host queries the constructed hostname. Because the domain is delegated to the attacker's authoritative server, the query eventually lands there instead of stopping at a caching resolver.
5. The attacker's server decodes the subdomain to recover the exfiltrated fragment.
6. Responses smuggle data back to the victim inside TXT records, NULL records, or the resolved IP address of an A record, giving the channel two-way communication for full interactive C2, not just one-way exfiltration.

Throughput and Tooling

The throughput is deliberately low, often just tens of kilobytes per hour once encoding overhead and query rate limits are accounted for, which is precisely why it survives detection efforts aimed at large, obvious transfers. An attacker using DNS tunneling for exfiltration is rarely trying to move gigabytes; they are moving credentials, small documents, or C2 tasking data where volume matters far less than the channel staying open and unblocked.

iodine and dnscat2 are the two tools most commonly referenced as examples of purpose-built DNS tunneling software. Both are open source and were originally built for legitimate uses such as tunneling internet access through captive portals or for red team engagements, which is also why their query patterns and encoding schemes are well documented and detectable once defenders know what to look for. Commodity malware families and custom C2 frameworks have also implemented their own DNS tunneling channels as a fallback communication method when HTTP-based C2 gets blocked.

Detection Signals

• Unusually high query volume to a single second-level domain.
• High-entropy or unusually long subdomain labels that do not resemble real hostnames.
• Rare record types at high frequency, such as TXT and NULL queries that are uncommon in normal traffic.
• Steady, sustained query rates to a domain rather than the bursty pattern normal DNS resolution produces.

Because the payload lives inside a protocol nobody thinks to inspect closely, catching tunneling depends entirely on treating DNS query logs as a first-class detection data source rather than plumbing to ignore.

Other Commonly Abused Protocols

FTP, Telnet, and SNMP get less attention than HTTP, SMB, and RDP, but each shows up often enough in real intrusions and legacy environments to be worth knowing well.

All three share a common thread: they were designed in an era before authentication and encryption were assumed defaults. Organizations that still run them are usually running them for legacy compatibility reasons that make patching or replacing them politically harder than it should be.

None of these three protocols need to be eliminated to be secured; each has a viable encrypted replacement or successor. The recurring lesson is that cleartext, legacy protocols do not disappear on their own. They linger because replacing them takes deliberate inventory and remediation work that competes for the same time and budget as everything else.

The Detection Mindset for Protocol Abuse

Every protocol covered in this chapter has a completely legitimate reason to exist on your network. That is not an incidental detail; it is the central fact that should shape how you build detections against protocol abuse. The signal worth chasing is almost never "this protocol is bad." It is "this instance of this protocol does not match how this protocol normally behaves in this environment."

Why Wholesale Blocking Fails

A detection built on the wrong premise produces one of two bad outcomes. Block or alert on a protocol wholesale, and you either break legitimate business functions, generating so many false positives that the alert gets tuned out or the rule gets disabled, or you get pushback from the business units that depend on the traffic and lose the detection entirely.

Ignore the protocol because it is "normal," and you miss the abuse happening inside it. Attackers specifically choose these protocols because they know defenders are reluctant to touch them.

Baselining as the Middle Ground

The workable middle ground is baselining: understanding what normal HTTP, SMB, RDP, DNS, and legacy protocol usage actually looks like in your specific environment, then building detections around deviations from that baseline rather than around the protocol itself. Which accounts normally use RDP, and to which hosts. Which service accounts normally touch ADMIN$ shares, and on what schedule. What the DNS query volume and entropy distribution looks like on an ordinary day.

A detection tuned to your environment's baseline catches the ransomware operator brute-forcing RDP without also flagging your help desk's routine remote support sessions.

Correlation Over Single Signals

Context and correlation matter more than any single indicator across every protocol in this chapter. A beacon-like HTTP interval, a new admin-share connection, an RDP logon from an unusual source, and a spike in TXT record queries are each individually explainable in isolation. Stacked together on the same host within a short window, they tell a very different story.

Building that correlation logic, rather than chasing single-signal alerts, is what separates a detection program that catches protocol abuse from one that just generates noise about protocols doing what protocols normally do.

Carry this mindset forward into the next chapter, which builds directly on it: turning the protocol-level behaviors described here into concrete network detections, the log sources that surface them, and the specific query logic that separates a legitimate administrative session from an intrusion in progress.