Successfully reported this slideshow.

Roll your own Botnet CnCs

0

Share

1 of 21
1 of 21

Roll your own Botnet CnCs

0

Share

Download to read offline

This presentation is look at common flaws in Botnet Control Architectures as well as a description of my attempt at designing a more secure architecture using Python. It was presented in April, 2016 at the Security BSides: Tampa Conference.

This presentation is look at common flaws in Botnet Control Architectures as well as a description of my attempt at designing a more secure architecture using Python. It was presented in April, 2016 at the Security BSides: Tampa Conference.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Roll your own Botnet CnCs

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. https://en.wikipedia.org/wiki/Fast_flux DNS Robtex Analysis of a Fast flux domain
  14. 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. 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
  16. 16. Python DNS Tunnel
  17. 17. 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. 
  18. 18. 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
  19. 19. 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
  20. 20. 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

×