This document discusses strategies for designing resilient command and control architectures for botnets, including using multiple domains with fast fluxing DNS, hosting servers on trusted platforms like GitHub, and obscuring communications with encryption and steganography. Python is recommended for implementation and HTTPS, DNS, and steganography are described as effective communication channels that can avoid detection. Designing private signing schemes and avoiding single points of failure are advised to make botnets resilient to takedowns.

1. whoami

Security researcher. Code monkey. Beer lover.

Head of Red Team Ops.

Primary security researcher

Study bot nets with a focus on alt. CnC schemes

Blog about stuff, sometimes.
https://the-it-ninja.blogspot.com/
https://www.linkedin.com/in/daniel-reilly-58b28171

2. What this talk is NOT about

Building Bots (There is plenty on this)

Protocol details (There are a lot of them)

Every CnC architecture
− Storm Style P2P (Overnet)

Exploiting anything (sorry!)

Designing a web interface

3. What this talk IS about

Designing Resilient CnC architectures

Using Python to build cool stuff

Virtuous vs. Malicious bot nets

Trust anchors (public/private keys/passwords)

Thinking about different ways to pass information.

4. Why R.Y.O.

Avoid Detection
− Keep your CnCs off blacklists by customizing their
fingerprint

Customize Attacks
− Design your Control Servers with an idea of the
objectives for your bots
− Only use communication methods that make
sense in your environment. Do not use IRC. Pretty
much ever.

Bypass Firewall Rules
− Most companies still rely on Blacklisting or

5. Botnet Taxonomy
A Bot net taxonomy model from North Western
University's CS department.

Attacking Behavior (Info stealing)

Rally Mechanisms (static or random)

Communication Protocols (DNS, HTTPS, etc.)

Observable bot net activities (Host, Network and
Global Correlated monitoring)

Evasion Techniques (Fast Flux)
http://www.cs.northwestern.edu/~ychen/classes/msit458
-s09/Botnets_defense.ppt

6. Architectural Goals

Resilient to take-down
− Multiple domains for DNS rally points.
− Fast Flux DNS server Ips for as many DNS
servers as you can manage to harvest
− Private GitHub accounts, SIP servers, etc.
− Test your server UI for command and SQL
injection
− Private Key sign commands and encrypted
responses
− Station To Station Encryption

Avoid detection

7. Layered/Distributed Architecture
Two examples of Distributed architecture. Web
servers are API points which talk to the
underlying DNS points
1. diagram 1 shows a bot master connecting via
Tor to the CnC web layer which manage 4 rally
points.
2. diagram 2 shows a recursive or “me-
centralized” network where the primary cnc
distributes commands to all other API points
which repeat this until an API point with no
rallypoints is reached.

8. Communication Channels

HTTPS (HTTPLib)
− Hides well in normal traffic
− Encrypted == Trusted (DPI mostly ignores it *see
note below)
− GitHub, Slack, Twitter, Custom Site, etc.
*As of IDP Release 5.0r2, Juniper IDP devices
support inspecting HTTPS traffic without the
servers private key
− Stego to obscure data transfers

SSH (Paramiko, SSHCommander)
− No client side piece (just an RSA key)

9. Where to put CnC Servers

“Borrowed” Servers (Outside the scope of this talk)
− Web shells
− Web App Exploits & Service Exploits

GitHub & other source code repos
− Almost no company blocks these sites
− Private accounts offer security
− Public accounts offer anonymity

Image/Video/File hosting sites
− S3 buckets, Dropboxes, Email Hosts, anywhere
you can store information can become part of your
CnC architecture

10. GitHub as a CnC platform

Generally Trusted

Great for virtuous botnets, okay for malicious
bots too.

A good start on this was done by Justin Seitz
in “Black Hat Python”.

To use the python library github3.py you need
to include it or wrap it in with your bot

Discovery exposes all bots associated with
that GitHub branch. Activity can be monitored
by anyone with bot credentials, even if they
can't decipher contents.

11. Who knows who this is?

What if 11B-X-1371 is a new method of CnC?
− Around 3000 still images compose the 2:00 video
− Audio Track can also hide data (not just the
Spectrographic images either).

YouTube, Vimeo, etc., all have posting APIs that
make them great locations to communicate with bots.

Traffic to these sites is high on a lot of networks

APT29 delivers HAMMERTOSS using
Steganography already!
Demo LOSTDOG

12. DNS Fast Flux (boto.route53)

Single Flux updates “A” Records (list of IP
associated) for a domain.
− Used to rapidly change the list of known servers
available to bots. Can be other bots or CnC points.
− Bypasses IP blocking
− Looks like a Load-Balancer unless you map it over
time

Double Flux also updates “NS” Records
− Use this to change a bots DNS rally points
− Double flux is ~twice as hard to detect and block

All the “cool kids” are doing it.

13. https://en.wikipedia.org/wiki/Fast_flux DNS Robtex Analysis of a Fast flux domain

14. How to build the CnC

Obfuscate communication channels
− HTTPS Encryption
− Steganography
− Onion routing
− Port Knocking

Language: Python
− Paramiko (SSH module)
− Github3
− Stepic (stego module)
− Py2Exe or PyInstaller to compile binaries

15. DNS For Comm (tunneling)

E.G. FeederBot, Morto (~2010)
− Use valid DNS TXT record requests
− Inject Shellcode directly into memory

Hard to block
− Combining Fast Flux with DNS tunneling creates a
resilient rally point layer
− All record types (MX, NS, A, TXT, C, etc) can be
used so blocking TXT is not an effective
prevention mechanism.

Drawbacks
− DNS servers can be compared to network settings

17. Python DNS Tunnel

18. HTTPS For Comm

HTTPS Used to communicate larger amounts
of data

Multiple parts of the CnC arch. rely on this
− Bot → Website data dumps
− Master → CnC command propagation
− CnC → Website Data retrievals

Larger bot commands
− Bot pulls new python modules from Github repo
− Allows for nearly limitless configurations of the
CnC arch.


19. How NOT to Build the CnC

RA1NX
− unauthenticated “pubcall” method
− PHP/IRC portals in general

Torpig
− Reverse Engineered Domain Flux algorithm in bot
− Hijacked botnet because of trusting bots.

Zemra Bot
− Intentionally backdoored

ICE IX, Citadel, or Zeus
− Exposed through Google Dorks

20. Push Instead of Pull

Good
− Bots passively listen for commands on an SSH
port
− Discovering a bot does not expose bot net size
− No knowledge of Bot Master to leak
− Good for CnC layer updating
− Talk given on doing this in javascript by Diogo
Mónica and Carlos Ribeiro

https://www.youtube.com/watch?v=6iM2jbheJ-0

Bad
− Relatively easy to block. Most networks block

21. Detecting private CnC Servers

HoneyNet YAPDNS for Fast Flux detection

https://github.com/honeynet/yapdns

Custom ClamAV/YARA Signatures

DetectPyDNSResponder:0:646e736c6962*444e5352
65636f72642e70617273650

iptables -I INPUT -p tcp ! -s <DNS_IP> --dport 53 -j
LOGIT

LOGIT chain checks ! -s <DNS_IP_2> and either
logs it as a primary DNS failure and jumps to
ACCEPT or as an attack and DROPs