IRC vs HTTP C&C
The Two Paradigms
Section titled “The Two Paradigms”From 2002 to approximately 2007, virtually every major botnet family in this collection used IRC (Internet Relay Chat) as its command-and-control protocol. By 2009, Zeus had demonstrated that HTTP was not just viable but superior for data-centric criminal operations. This page examines why the shift happened, what it meant technically, and how it reshaped both offense and defense.
Comprehensive Comparison
Section titled “Comprehensive Comparison”Protocol & Network Architecture
Section titled “Protocol & Network Architecture”| Dimension | IRC Botnets (sdBot → 120-Series) | HTTP Botnets (Zeus) |
|---|---|---|
| Connection model | Persistent TCP connection to IRC server | Stateless HTTP POST polling at configurable intervals |
| Default ports | 6667, 6668, or non-standard (often flagged) | 80 (HTTP) / 443 (HTTPS) - blends with legitimate traffic |
| Protocol overhead | IRC protocol framing + channel management | Standard HTTP request/response |
| NAT traversal | Problematic - requires port forwarding for inbound | No issues - outbound HTTP works behind any NAT/proxy |
| Traffic pattern | Continuous connection with periodic PING/PONG | Brief periodic check-ins; indistinguishable from web browsing |
| Network visibility | IRC traffic on any port is anomalous in enterprise networks | HTTP/HTTPS traffic is expected and voluminous |
Encryption & Security
Section titled “Encryption & Security”| Dimension | IRC Botnets | HTTP Botnets (Zeus) |
|---|---|---|
| Early era (2002–2004) | Plaintext commands and responses | N/A |
| Mid era (2004–2005) | BlowSXT introduced Blowfish encryption; non-printable prefix (\xBB) | N/A |
| Late era (2007+) | Some variants used SSL IRC connections | N/A |
| Zeus (2009) | N/A | RC4 encryption on all payloads + MD5 integrity verification from day one |
| Authentication | IRC channel password + host mask matching + multi-login tracking | Session-based web panel auth + MD5 password hashing + 15+ permission flags |
| Command verification | Plaintext prefix matching (.command or \xBB prefix) | Binary TLV (Type-Length-Value) format with cryptographic integrity |
Scalability
Section titled “Scalability”| Dimension | IRC Botnets | HTTP Botnets (Zeus) |
|---|---|---|
| Server capacity | Limited by IRC server connection limits (typically thousands) | Standard web servers handle 100K+ periodic HTTP requests easily |
| Bot registration | Joins IRC channel; nick collisions possible at scale | HTTP POST to gate.php; stateless, no persistent connection overhead |
| Bandwidth profile | Continuous idle connections consume server resources | Brief periodic polls; server idle between check-ins |
| Multi-botnet | Requires separate channels or servers | Single panel manages multiple botnets via database filtering |
| Geographic distribution | IRC server location is a single point of latency | Standard web hosting, CDN-compatible, multi-region deployable |
Administration & Usability
Section titled “Administration & Usability”| Dimension | IRC Botnets | HTTP Botnets (Zeus) |
|---|---|---|
| Operator interface | IRC client (mIRC, BitchX, etc.) - command-line style | Full web GUI with dashboards, filtering, RBAC |
| Bot visibility | Channel user list + nick-based identification | Database-backed bot list with IP, country, OS, NAT status, online state |
| Command deployment | Type command in channel/topic; all bots execute | Script system with targeting: bot ID whitelist/blacklist, botnet name, country code, send limits |
| Data retrieval | Bots paste stolen data into IRC channels (unstructured) | MySQL database with structured tables, searchable by date/type/source |
| Multi-user | Limited - IRC auth levels (op/voice) | Granular RBAC - 15+ per-user permission flags |
| Reporting | None built-in | Statistics dashboard: installs by country, OS distribution, infection rates |
| Learning curve | Requires IRC protocol knowledge | Point-and-click web interface accessible to non-technical operators |
Targeting & Data Handling
Section titled “Targeting & Data Handling”| Dimension | IRC Botnets | HTTP Botnets (Zeus) |
|---|---|---|
| Primary purpose | DDoS, spam relay, spreading, general-purpose | Banking fraud, credential theft, financial crime |
| Target precision | Broad - all bots receive all commands | Per-country, per-botnet, per-bot-ID targeting |
| Data types | CD keys, keylog dumps, IRC channel paste | HTTP/HTTPS requests, FTP/POP3 credentials, form grabs, certificates, cookies, arbitrary files |
| Data organization | Lost in IRC scrollback unless manually logged | Structured MySQL tables: Reports > DB searchable by date, type (HTTP/HTTPS/FTP/POP3/grabbed) |
| Data volume | Limited by IRC message rate limits | Web server handles high-volume log uploads efficiently |
Resilience & Takedown Resistance
Section titled “Resilience & Takedown Resistance”| Dimension | IRC Botnets | HTTP Botnets (Zeus) |
|---|---|---|
| Single point of failure | IRC server(s) - typically 1–2 with failover | Web server(s) - but easier to proxy/migrate |
| Domain strategy | Hardcoded IP or hostname; some used DNS failover | Dynamic domains, fast-flux DNS, proxy chains (redir.php) |
| Law enforcement response | Identify and seize IRC server(s) | More complex - distributed hosting, bulletproof providers, domain registrar takedowns |
| Notable exception | Phatbot used P2P WASTE protocol (no central server) | GameOver Zeus (post-leak) added P2P, combining the best of both |
Why HTTP Won
Section titled “Why HTTP Won”The transition from IRC to HTTP C2 was driven by five converging factors:
1. Network Evasion
Section titled “1. Network Evasion”By 2005–2006, enterprise firewalls and IDS systems had learned to flag IRC traffic. Even on standard IRC ports, the protocol's distinctive framing patterns (JOIN, PRIVMSG, PING/PONG) were easily signatured. IRC on non-standard ports was even more conspicuous.
HTTP/HTTPS traffic, by contrast, is the most common protocol on any network. A bot making periodic HTTP POST requests to a PHP endpoint is virtually indistinguishable from legitimate web browsing, especially when encrypted with SSL/TLS. Zeus exploited this fundamental asymmetry.
2. Scalability Requirements
Section titled “2. Scalability Requirements”As botnets grew from thousands to millions of nodes, IRC servers became bottlenecks. IRC was designed for human-scale chat rooms, not for managing fleets of automated clients. Connection limits, nick collision handling, and the overhead of maintaining persistent TCP connections all degraded at scale.
HTTP's stateless request/response model scaled naturally. A standard web server could handle 100,000+ bots polling periodically with minimal resource consumption. The infrastructure knowledge was also commoditized - anyone could deploy a PHP/MySQL application on shared hosting.
3. Commercial Viability
Section titled “3. Commercial Viability”Zeus was sold as a commercial product on underground forums. This required:
- A user-friendly interface - web panels with point-and-click administration replaced IRC client expertise
- Multi-user support - role-based access control allowed criminal organizations to delegate tasks
- Structured data - MySQL databases with search/filter capabilities replaced IRC scrollback
- Reporting - statistics dashboards showed infection rates, geographic distribution, and ROI
None of this was practical with IRC-based architecture.
4. Data-Centric Design
Section titled “4. Data-Centric Design”The IRC bots in this collection were fundamentally action-oriented - they received commands and executed tasks (DDoS, scan, spread). Data theft was a secondary capability bolted on (keylog dumps pasted into IRC channels, CD keys broadcast to operators).
Zeus was data-oriented from the ground up. Its entire architecture was designed to collect, organize, and monetize stolen financial data:
- Man-in-the-Browser hooks captured data silently
- Structured database tables categorized stolen credentials by type and source
- Web injects targeted specific banks with customized phishing overlays
- The operator searched and exported data through a web interface
5. Operational Security
Section titled “5. Operational Security”IRC botnets leaked operational information inherently:
- Channel names, server addresses, and operator nicks were visible to anyone who joined
- Bot nicks in channel lists revealed botnet size
- Commands typed in channels could be observed by infiltrators
- IRC server logs recorded everything
Zeus's HTTP model provided natural compartmentalization:
- No persistent connections to observe
- Encrypted payloads prevented content inspection
- Web panel access required authentication
- No equivalent of "joining the channel" for researchers
The Transition Period (2005–2008)
Section titled “The Transition Period (2005–2008)”The shift wasn't instantaneous. Several intermediate approaches emerged:
IRC with Encryption (2004–2005)
Section titled “IRC with Encryption (2004–2005)”BlowSXT added Blowfish encryption to IRC C2 and changed the command prefix to a non-printable character (\xBB). This addressed content inspection but not the fundamental protocol visibility problem.
IRC over SSL (2005+)
Section titled “IRC over SSL (2005+)”Some variants (notably Phatbot) supported SSL-encrypted IRC connections. This prevented content analysis but the connection patterns (persistent TCP to non-standard ports) remained anomalous.
P2P Alternatives (2003–2005)
Section titled “P2P Alternatives (2003–2005)”Phatbot's WASTE protocol eliminated the central server entirely, creating a resilient mesh network. However, P2P introduced its own problems:
- Complex implementation - difficult for the community modification model
- Latency - commands propagated slowly through the mesh
- Monitoring - researchers could join the mesh network as peers
- No structured data handling - same limitation as IRC for data-centric operations
DNS-Based Tricks (2005+)
Section titled “DNS-Based Tricks (2005+)”AkBot used DNS SRV records for C2 resolution - a precursor to domain-generation algorithms (DGAs) that would later become standard in HTTP-based malware.
The IRC Bot Response
Section titled “The IRC Bot Response”The later IRC bot variants in the collection show awareness of HTTP's advantages and attempted to compensate:
| Feature | IRC Bot Implementation | Zeus Equivalent |
|---|---|---|
| Encryption | Blowfish C2 (BlowSXT), XOR config (120-Series) | RC4 + MD5 on everything |
| Stealth | CTCP camouflage (fake mIRC/BitchX/xchat/irssi responses) | Native HTTP blending |
| Persistence | Multi-server failover, topic commands | Domain rotation, proxy chains |
| Data theft | Keylogger, packet sniffer, credential dump | MitB, web injects, form grabbing |
| Organization | Namespace prefixes (irc., root., ddos.*) | Database categories, searchable reports |
Despite these efforts, the IRC model had inherent limitations that no amount of bolted-on features could overcome.
Impact on Defenders
Section titled “Impact on Defenders”What Worked Against IRC Bots
Section titled “What Worked Against IRC Bots”- Port blocking: Block outbound IRC ports (6667–6669) at the perimeter
- Protocol detection: IDS signatures for IRC protocol framing
- Channel monitoring: Infiltrate C2 channels to observe commands and enumerate bots
- Server takedown: Seize or null-route the IRC server to decapitate the botnet
- Nick analysis: Bot nicks often encoded system info (uptime, OS) - useful for intelligence
What Broke Against HTTP Bots
Section titled “What Broke Against HTTP Bots”- Port blocking: Cannot block ports 80/443 without breaking all web access
- Protocol detection: HTTP POST to a PHP endpoint looks identical to legitimate web traffic
- Channel monitoring: No channel to join; encrypted payloads prevent content inspection
- Server takedown: Distributed hosting, bulletproof providers, rapid domain rotation
- Traffic analysis: Brief periodic polls blended into normal web traffic patterns
New Defensive Requirements
Section titled “New Defensive Requirements”The HTTP shift forced the security industry to develop entirely new capabilities:
- SSL/TLS inspection - Decrypt outbound HTTPS to inspect for C2 traffic
- Behavioral analysis - Detect malware by what it does (browser hooking, credential access) rather than how it communicates
- Domain reputation systems - Score newly registered domains, hosting patterns, DNS behavior
- Endpoint Detection & Response (EDR) - Monitor process behavior, API calls, memory modifications
- Threat intelligence sharing - Financial sector ISACs (Information Sharing and Analysis Centers) for Zeus IOCs
- Browser hardening - Sandboxing, Content Security Policy, certificate pinning to resist MitB
- Two-factor authentication - Rendering stolen passwords alone insufficient for financial fraud
Legacy
Section titled “Legacy”The IRC-to-HTTP transition documented in this collection represents one of the most consequential architectural shifts in cybersecurity history. It transformed botnets from tools of disruption (DDoS, spam) into platforms for organized financial crime. The Zeus model - HTTP C2, web panels, encrypted communications, structured data - became the template for virtually all subsequent crimeware: Citadel, Dridex, Emotet, TrickBot, and beyond.
The IRC bot families in this collection (sdBot through the 120-Series) are not obsolete curiosities - they document the evolutionary pressures that drove the paradigm shift. Understanding why HTTP won requires understanding what IRC couldn't do, and that understanding remains directly relevant to analyzing modern C2 architectures.