Beyond the Web: Non-HTTP Strikes in CyPerf

Introduction

When people think about network attacks, they usually picture HTTP: a malicious URL, a poisoned form field, a crafted JSON body. Web traffic dominates modern networks, so that makes sense. But a large part of the attack surface sits behind other protocols: mail servers speaking SMTP and IMAP, file servers speaking SMB, databases speaking Redis' wire protocol, and appliances that expose their own management protocols. Several of the vulnerabilities in this article (Zimbra, FortiSIEM, Redis, Samba) are exploited without ever touching an HTTP parser.

A firewall or IPS that only does well on web traffic is only partly tested. Keysight's CyPerf covers this with non-HTTP strikes: simulated attacks, researched and maintained by Keysight's Application and Threat Intelligence (ATI) team, carried by application-layer protocols that run above Layer 4 (over TCP/UDP) but are not HTTP. Security devices under test, such as firewalls and intrusion prevention systems, are called DUTs (devices under test) in the rest of this article. This article explains what non-HTTP strikes are, how CyPerf replays them, which categories of attacks they cover, and walks through four examples, each with the traffic CyPerf actually puts on the wire.

What Do We Mean by "Non-HTTP"?

The usual Layer 4 transports are TCP and UDP. On top of them sit application-layer protocols, and a security device has to decode those protocols to understand what is being attacked. For this article, a non-HTTP strike is a strike whose attack travels over one of those protocols without being wrapped in HTTP: mail, file sharing, remote access, databases and middleware, management interfaces, and core infrastructure services such as DNS and TLS.

The same concepts from CyPerf's general strike library apply here. For a broader introduction to CyPerf strikes, you can read CyPerf Strikes: An Overview of Simulated Exploits and Vulnerabilities. Every strike has a direction (client-to-server c2s or server-to-client s2c), a severity, references such as CVE and CVSS, and keywords you can filter on in the Attack Library and Customize Attack tabs (for example target, vector, intent, severity and direction). What differs is the content on the wire: there is no HTTP request line, no HTTP headers, and no HTTP body :D. A device that wants to detect the attack has to recognize the protocol first, then parse it, then find the malicious part.

How CyPerf Runs a Non-HTTP Strike

Each non-HTTP strike is a conversation between the CyPerf client and server agents, usually replayed on a single connection to the protocol's default port (for example 6379 for Redis, 445 for SMB, 25 for SMTP). One side sends a block of bytes and the other side expects to receive exactly those bytes.

Three properties make this useful for testing a DUT:

1. It looks like the real protocol. The setup (login, handshake, session negotiation, etc) is replayed in order, so a protocol-aware DUT has the context it needs to decode what follows.
2. The receiver validates what arrives. The receiving endpoint waits for the exact byte stream, so a DUT that drops, resets, or rewrites the connection prevents the strike from completing.
3. Every strike reports its own result. The last step of each strike increments a counter for that strike, so the test statistics show, strike by strike, whether the attack made it through. The All Strikes statistics view lists c2s and s2c strikes in separate tables, with counters such as Client Started, Client Allowed and Client Blocked for c2s strikes, and Server Initiated, Client Allowed and Client Blocked for s2c strikes. Figure 1 shows a test with one strike of each direction and no DUT in the path: each strike was started once, allowed once, and never blocked. The same holds for the captures shown below, where every strike completes.

Figure 1: CyPerf's All Strikes statistics after a test with one c2s and one s2c strike and no DUT in the path

What the Non-HTTP Strikes Cover

CyPerf's non-HTTP strikes fall into a handful of categories. Each one stresses a different part of a DUT: some need deep protocol decoding, some need content inspection after decoding, and some only show up if the DUT inspects traffic flowing toward the client.

• Mail delivered over SMTP. This is the largest family. Most of these strikes send an email whose attachment (an Office document, a PDF, an image, a media file) exploits the application that opens it. Many exploits come in several variants that encode the same attachment in Base64 and in Quoted-Printable, so a DUT has to decode the MIME part before its file signatures can match. The SMTP category also covers attacks on mail infrastructure itself, such as the Zimbra example below, where the malicious part sits in the SMTP dialogue rather than in the message.
• Mail fetched over IMAP4. The same kind of malicious attachments, this time delivered by a malicious mail server to a user's mail client. These strikes are s2c: only a DUT that inspects traffic going toward the user sees them.
• File sharing and file transfer. SMB1 and SMB2 attacks against Windows and Samba file servers, and memory-corruption flaws in FTP servers triggered by crafted commands and arguments.
• Remote access. Legacy terminal services such as Telnet and rlogin, including authentication bypasses, privilege escalation and command injection in services and devices managed over them, and a remote-desktop client attacked by a malicious server.
• Databases, middleware and management interfaces. Database wire protocols such as Redis' RESP, application-server middleware protocols, and the proprietary management and monitoring protocols of telephony and security products, such as FortiSIEM's. These services are rarely meant to face the internet, but when they are reachable, they are high-value targets.
• Core infrastructure. DNS over UDP, where a malformed reply targets the software that resolves it, and raw SSL/TLS handshakes, including legacy protocol versions and crafted handshake data.

A few observations about these categories:

• The same exploit often travels several ways. A malicious document can arrive over SMTP, over IMAP4, in Base64 or in Quoted-Printable. A DUT that blocks one variant and misses another has a gap that an attacker only needs to find once.
• Old vulnerabilities still matter. Many of the mail and file-sharing strikes target flaws that are more than a decade old. Unpatched legacy systems still live on real networks.
• The newest strikes target network-exposed services. The most recent vulnerabilities (Zimbra, FortiSIEM, Redis) are all server-side flaws in services that listen on the network.

All of the examples below are vulnerabilities from 2021 or later.

Examples

About the Capture Figures

The capture figures in the examples below (Figures 2 to 5) are rendered from packet captures taken while running each strike in CyPerf with no DUT between the agents. Depending on the protocol, a figure shows the payload as text, the list of frames that carry data, or a decoded view of the protocol messages inside those frames. Red is sent by the client, blue by the server, and yellow callouts mark the part of the traffic that matters the most. Non-printable bytes appear as dots, and long payloads are truncated where marked.

Strike Redis XACKDEL Command Stack Buffer Overflow

CVE-2025-62507 | Year: 2025 | Direction: c2s | Severity (CyPerf): High | CVSS v3: 8.8 | Protocol: Redis RESP over TCP/6379

Vulnerability Description: Redis 8.2 added the XACKDEL command for Streams. Per the Redis security advisory, the code does not handle the case where the number of IDs in the request exceeds a fixed-size internal buffer (STREAMID_STATIC_VECTOR_LEN) and skips the memory reallocation it should perform, which causes a stack-based buffer overflow. In the Redis source, that buffer is a stack array of 8 stream IDs. The advisory lists Redis 8.2.0 and later as affected, with the fix in 8.2.3, which adds the missing heap allocation for larger requests, and it rates the overflow as one that "may potentially lead to remote code execution". The CVSS vector requires a low-privileged (authenticated) user. The issue was reported by Google Big Sleep.

Figure 2: The Redis strike authenticates, creates a consumer group, then sends one XACKDEL call with 83 IDs

What the Capture Shows:

• The client authenticates (AUTH backup ghyc) and the server answers +OK, matching the advisory's scenario of an authenticated, low-privileged user.
• A second command creates a stream and a consumer group (XGROUP CREATE KRuHEQe PIh $ MKSTREAM). This step is required: XACKDEL returns early if the key or the group does not exist, before it reaches the vulnerable code.
• The last client message is a single RESP array of 88 elements and 2,194 bytes: XACKDEL KRuHEQe PIh IDS 83, followed by 83 stream IDs, more than ten times the 8 the stack buffer holds.

How It Works: RESP frames every command as an array of length-prefixed strings, so the oversized request is syntactically perfect. Nothing is malformed. The only abnormal property is the count of IDs: the vulnerable code parses every ID into the 8-entry stack array, and the IDs past the eighth overwrite whatever follows it on the stack.

Consequences:

• Denial of Service: The Redis process can crash
• Possible Remote Code Execution: Stack corruption may be turned into code execution
• Mitigation without patching: Restrict the command with Redis ACLs

References:

• Redis security advisory GHSA-jhjx-x4cf-4vm8
• Dissecting and Exploiting CVE-2025-62507: Remote Code Execution in Redis (JFrog)

Strike Fortinet FortiSIEM elastic_test_url.sh Argument Injection

CVE-2025-64155 | Year: 2025 | Direction: c2s | Severity (CyPerf): High | CVSS v3: 9.8 | Protocol: FortiSIEM phMonitor over TCP/7900

Vulnerability Description: FortiSIEM's phMonitor service exposes its command handlers over a custom TCP protocol, and per Horizon3.ai's research none of them require authentication. The handler for storage requests accepts an elastic storage type and builds a call to the elastic_test_url.sh script from user-controlled XML fields. The script constructs a curl command and appends the <cluster_url> value to the end, so an attacker can inject curl arguments. Horizon3 used this to write arbitrary content to arbitrary paths as the admin user, and chained it with a second flaw to reach root. Fortinet's advisory (FG-IR-25-772) lists the Super and Worker nodes as affected, but not Collector nodes, and gives limiting access to the phMonitor port (7900) as a workaround.

Figure 3: The FortiSIEM strike sends one message; the cluster_url field carries curl options

What the Capture Shows:

• A single 486-byte client message after the TCP handshake, with no reply from the server. The message starts with a short binary header (the dots in the figure) and continues with a <TEST_STORAGE type="elastic"> XML document.
• The <cluster_url> field does not contain a URL. It contains curl options: --proto-default file /dev/null --next file:///proc/self/cmdline -o /tmp/heqaeg --next file:///tmp/heqaeg -r178-192 -o /tmp/heqaeg -w ....

How It Works: The --next option makes curl chain several operations in a single execution. Here the chain reads a local file, writes it to an attacker-chosen path with -o, and reads part of it back. The strike performs only harmless file operations, but a real attack uses the same primitive to overwrite a file the appliance executes. There are no shell metacharacters involved, so filters that look for ;, | or backticks do not help.

Consequences:

• Unauthenticated Remote Code Execution on the appliance (as admin through this flaw alone)
• Path to Root: Horizon3 chained it with a second bug to reach root
• Sensitive Position: FortiSIEM collects security telemetry from across the network

References:

• Horizon3.ai: CVE-2025-64155, Three Years of Remotely Rooting the Fortinet FortiSIEM
• Horizon3.ai proof of concept
• Fortinet PSIRT advisory FG-IR-25-772

Strike Zimbra Collaboration postjournal Command Execution Vulnerability

CVE-2024-45519 | Year: 2024 | Direction: c2s | Severity (CyPerf): Critical | CVSS v3: 10.0 | Protocol: SMTP over TCP/25

Vulnerability Description: Zimbra's postjournal service accepts SMTP. When it expands recipient addresses, its read_maps function builds a shell command from the recipient data and runs it with popen without sanitization. Per ProjectDiscovery's analysis, the address is wrapped in double quotes, which blocks simple metacharacters, but $() command substitution still works. An unauthenticated attacker can run commands as the Zimbra user, and CISA added the flaw to its KEV catalog in October 2024. Two preconditions apply: the postjournal service is not enabled by default, and the attacker must be able to deliver mail to it, which under Zimbra's default relay restrictions means being in mynetworks or being authenticated.

Figure 4: Client side of the Zimbra strike; the command substitution sits in the RCPT TO address

What the Capture Shows:

• A complete SMTP session: EHLO, MAIL FROM, RCPT TO, DATA, a one-line message body, ., and QUIT. The figure shows the client side, where the whole attack lives.
• The RCPT TO line is the attack: RCPT TO: <"yLT9yUfJA6BfVZ$(/bin/pwd)"@fYRuRNYdAlfEcUGYH.gov>. The harmless /bin/pwd stands in for the command a real attacker would use.
• The message body itself is a single line of random text. Nothing malicious is in it.

How It Works: SMTP allows a quoted string as the local part of an address, and $(...) is shell command substitution. When the vulnerable service builds a shell command from the recipient, the shell evaluates the substitution. Because the injection sits in an SMTP command and not in the message body, scanning the message content never finds it. The device has to inspect the SMTP dialogue.

Consequences:

• Command Execution on the Mail Server as the Zimbra user, with no credentials
• Exposed by Design: Mail servers listen for traffic from the outside, though the postjournal precondition limits how many are vulnerable
• Low Effort: One crafted SMTP session is enough

References:

• Zimbra Remote Code Execution (ProjectDiscovery)

Strike Samba vfs_fruit module Out-of-Bounds read-write

CVE-2021-44142 | Year: 2021 | Direction: c2s | Severity (CyPerf): High | CVSS v3: 8.8 | Protocol: SMB over TCP/445

Vulnerability Description: Samba's vfs_fruit module adds compatibility with Apple clients. Per the Samba advisory, the flaw is in the parsing of extended-attribute (EA) metadata when smbd opens files, and it is an out-of-bounds heap read/write. Exploitation requires a user with write access to a file's extended attributes (the advisory notes this could be a guest or unauthenticated user if such access is allowed), and Samba installations with the default fruit settings (fruit:metadata=netatalk or fruit:resource=file) are affected. The advisory says remote attackers can execute arbitrary code as root. All versions before 4.13.17 are affected, and fixes shipped in 4.13.17, 4.14.12 and 4.15.5.

Figure 5: The Samba strike's SMB2 session ends with a crafted org.netatalk.Metadata attribute

What the Capture Shows:

• The client's messages travel in two TCP segments: 1,846 bytes carrying eight SMB messages, then a 176-byte segment with the last one.
• The session starts with an SMB1 Negotiate that offers dialects including SMB 2.002, followed by an SMB2 NEGOTIATE, two SESSION_SETUP requests, a TREE_CONNECT and a CREATE for a file (rivdekm).
• The SET_INFO request writes an extended attribute named org.netatalk.Metadata with 402 bytes of data. The data begins with 00 05 16 07, the magic number of the AppleDouble format that vfs_fruit parses.
• A second CREATE opens the stream rivdekm:AFP_AfpInfo, and a final WRITE stores 60 bytes into it.

How It Works: Everything before SET_INFO is normal client behavior: negotiate, log in, connect to a share, create a file. The crafted metadata is then stored on the file, and when vfs_fruit parses that metadata as the file is opened, the malformed content triggers the out-of-bounds access.

Consequences:

• Remote Code Execution: Per the advisory, as root, on Samba servers with vfs_fruit in use
• Wide Deployment: Samba is the standard SMB server on Linux and in many NAS appliances

References:

• Samba security advisory for CVE-2021-44142

Conclusion

HTTP is the best-known battlefield, but not the only one. The non-HTTP strikes in CyPerf cover the protocols that carry email, files, databases, management and infrastructure traffic: from legacy mail and SMB exploits to Redis and FortiSIEM in 2025, and from single-command injections to complete multi-step SMB sessions. Each strike replays the protocol conversation in order, places the exploit where it would appear in a real attack, and records whether the DUT let it through. Used together with CyPerf's web, AI/LLM and malware strikes, they give a more complete picture of a security device than testing web traffic alone. If your security stack inspects more than HTTP, these strikes show how well.

Related Posts