Botnets are responsible for many of the cyber attacks we encounter these days; from DDoS and spam attacks to keylogging and click fraud. In today’s post, we take a closer look at how a botnet attack works – how it gains a foothold into each botnet slave, how each slave communicates with the C&C servers, and how the entire botnet carries out nefarious acts.
All botnets are networks of enslaved devices known as “bots”. That’s really where the term “botnet” comes from. And so, before a botnet comes into existence, a large number of devices must first be infected with malware that turn these devices into unwitting bots (a.k.a. zombies).
So how do these devices get infected in the first place? Well, it depends on the type of device. In the case of desktops, laptops, phones, and tablets, these devices typically get infected when the people using them either:
- Visit a malicious site and download malware without noticing it (a.k.a. drive-by-download) or
- Consciously download a file through an email or website without knowing it’s actually malware (a.k.a. a trojan).
In the case of IoT devices, they usually get compromised after attackers actively break into them. For example, the attacks that ensnared IoT devices into the Mirai botnet and Mirai-wannabes, the attackers used automated tools that scanned networks for weak passwords, broke in through brute force, and installed the malware.
Once devices become infected and become bots, they then communicate with the command and control servers or C&Cs.
The C&Cs are the servers that deliver commands to the bots, directing them to targets and instructing them what to do. Traditionally, botnets operate under a client-server model, wherein the bots act as the botnet clients and the C&Cs act as the servers. There can be one or more Command and Control servers in a botnet.
Having multiple C&Cs provides redundancy and enables botnets to acquire high availability capabilities. Meaning, if one C&C goes down, the botnet clients can still receive commands from the other C&Cs. Nevertheless, having multiple C&Cs doesn’t make a client-server-type botnet indestructible. Its survival still relies heavily on the C&Cs. If the C&Cs are identified and eventually brought down, the entire botnet will be no more.
This is how massive botnets like Mariposa and Bredolab were dismantled. After their C&Cs were tracked down, the end of these malicious networks became imminent.
Today, many botnets follow a different architecture. To avoid total reliance on a group of C&Cs, these botnets now use a P2P model, wherein each botnet client also functions as a C&C. This type of botnet is much harder to take down.
Most bots communicate with their C&Cs using either one of two communications protocols – IRC (Internet Relay Chat) or HTTP (HyperText Transfer Protocol). Other botnets also employ other communication methods but these two are definitely the most commonly used.
IRC communications can be easily automated (using scripts). In addition, open source IRC servers are readily available. That’s why this protocol used to be a perfect fit for botnet creation and deployment. During infection, a typical botnet malware would install an IRC client, which in turn would then communicate with the IRC server on the C&C.
The characteristics of IRC, while a boon for botnet operations, has ironically also become many a botnet’s undoing. If you really think about it, Internet Relay Chat is no longer a common method of communication (most people now use Instant Messaging applications). And so, ever since IRC became associated with botnets, the presence of IRC packets has often raised red flags. Some system admins even started blocking IRC packets in their firewalls.
It is for this reason that malware writers have started to turn to a more firewall-friendly option as their botnet communication protocol of choice. And what network protocol can be more firewall-friendly than HTTP? All websites (including popular ones like Google, Facebook, and Amazon) all communicate via HTTP. So if a botnet uses HTTP, there’s a lower chance of it getting flagged down because, unlike IRC packets, HTTP packets don’t easily stand out.
Zeus, one of the most notorious botnets ever, communicated via HTTP. In fact, several exploit kits incorporate HTTP communications into their botnet malware payloads.
One of the most common botnet attacks is the DDoS or Distributed Denial of Service attack. In this type of attack, all bots send out requests to a target server with the purpose of overwhelming it and preventing legitimate requests from getting through or processed.
Another common botnet attack – in fact, arguably the most common cyber attack that employs botnets – is sending out tons of spam. In a typical spam attack, bots send out spam emails to target email addresses with the purpose of getting click-throughs and, ultimately, generating ad revenue.
Botnets can also be used to steal information from enslaved devices. Some bot clients operate as keyloggers that record end user keystrokes. Keyloggers can, for example, record the password characters an end user enters during login and then send this information to the bot herders.
Lastly, botnets can also be used for click fraud activities. Bot clients can click on ads and trick ad networks that the clicks came from legitimate end users.
Preventing botnet attacks
Botnet malware infections can be avoided by educating end-users about the risks and best practices of downloading email attachments and visiting web sites. Of course, this countermeasure has its limitations. Most end users find security practices too tedious and time consuming, and often disregard them. Further, some threats (like drive-by-downloads) are just too difficult to avoid.
The best way would is to employ advanced malware protection solutions. These solutions typically combine advanced network behaviour analysis and real time intelligence to detect even the most stealthy malware infections.