Checklist 52: 5 Things to Understand About How Botnets Work
With malicious networks using tens of millions of computers and devices to serve up spam, run denial of service attacks, and more, botnets are a threat we can’t ignore. Five things to know about botnets: that’s the topic of today’s Checklist.
Is your computer a zombie? What about your Wi-Fi router? Millions of Internet-connected devices today are the unthinking slaves of some shadowy masters — those who control the massive “botnets” that cause chaos around the Web. Not all malware exists to create visible and obvious problems. Sometimes, all a hacker wants are machines that he can control to do his bidding with ease — all without ever letting the real users of these infected devices that anything is amiss.
This week, we’ll zoom in to take a closer look at botnets. With all these malicious networks enslaving tens of millions of computers and devices to serve up spam, deny service to important websites, and more, it’s a threat that we can’t ignore. So, what do you need to know about them, and how is the computer security sector fighting back against this growing problem? Let’s start with some background and definitions, so we have a good foundation for today’s Checklist discussion.
- What are botnets and how are they built?
- What do the bad guys do with botnets?
- How botnets communicate
- A look at some of the biggest botnets
- How security researchers fight back against botnets
What are botnets and how are they built?
So, the simplest definition we can create for “botnets” comes just from looking at the word itself: we’re dealing with a network of bots, or computers acting like a semi-autonomous “robots”, which acts on commands. For the most part, the machines swept up into these networks are Windows computers owing to the large number of exploitable vulnerabilities across its many versions. When users don’t apply patches promptly, it’s much simpler for hackers to build botnets with these machines than it currently is to target Macs for nefarious purposes.
Desktop computers aren’t the only devices that end up enslaved in botnets, though — in fact, botters might be moving away from them as a dominant source for zombie devices. The growth of the Internet of Things and the lack of strong security in many of those consumer devices makes them an appealing target.
Just a few years ago, a botnet of several hundred thousand IoT devices was built on the back of a vulnerability in a refrigerator! For those living with smart home devices, you might never know that your fridge is part of an international spam ring pumping out millions of phony emails a day. The well-publicized Mirai botnet that took down some ISPs this year is another good example of that. IoT products, business workstations, laptops, desktops — if it connects to the web, someone will want to harness its power for a botnet.
Before we dig into what botmasters do with the computing power available to them, how do they even come to control so many machines in the first place? The answer is malware, of course, but it comes in a more layered, sophisticated package than you’d expect from something designed to target one machine or the individual user. In these cases, the botmasters rarely care about who owns or uses a device they enslave. Instead, they might prefer to target enterprise-level computers in businesses or governments. Why?
Those computers are often very homogeneous in nature, sharing security patches and operating systems such that any vulnerability in one makes it probable there are more insecure machines nearby. Scanning local networks and jumping to infect those PCs is easy for botnet malware. That’s one way for the malware to end up on a hard drive, but it also comes in all the other ways you’d expect: malicious email attachments, drive-by downloads, and so forth. Those same methods can be used against regular home users as well.
Some bad guys use an initial Trojan horse virus to make their way onto a target machine. This Trojan either acts as a “dropper” to deploy the botnet payload, or it opens the door to the command and control server to send the correct software to the machine. Some Trojans even delete themselves to avoid detection later, leaving behind the harder-to-find malware. After entrenching itself on a computer, it may then begin to scan for more machines or go straight to engaging in malicious activity.
What do the bad guys do with botnets?
Once a hacker gains control of a botnet, they can turn it to many different purposes, like sending the spam we mentioned a moment ago. That is a small fraction of what else they can do with tens of thousands to even millions of machines responding to their commands. They might steal data from the host computers (in the case of a smaller, targeted botnet), blast out emails filled with more malware to help build the network, probe other computers for vulnerabilities, or — as we see more and more often — they might engage in a Distributed Denial of Service attack. It’s not hard to see how tons of computers working in unison could crash a web server with ease.
How could a hacker do all this without the users of the devices recognizing that something is wrong? Well, for starters, there might be no way to tell that anything is wrong in the first place: how can you run an anti-malware program on a Wi-Fi router or a smart thermostat? Botnets built on innocuous devices are hard to detect and harder to purge due to the inaccessibility of their systems.
Those clearly aren’t the only machines falling under their control — so how does the average computer user manage to miss what’s going on? It’s surprisingly simple: the hackers do almost as little as possible with each machine. For example, let’s think about a botnet built for racking up advertising dollars through fraud. Instead of waiting for real people to see the ads in question, they deploy malware that controls a user’s web browser and directs traffic to the places the botmaster chooses.
Obviously, a flood of requests that slows down a user’s connection or takes over their browser won’t work. The bad guys need to use a subtler approach, so these actions usually take place in hidden or background processes. They access only enough browser resources on each machine to send a few requests. When you add everything together, with the huge number of bots in the network, it’s easy to see those few requests add up to huge numbers.
Spam is the goal in other cases, with botted machines acting as SMTP, or email, servers. Anti-spam methods have grown considerably in recent years, and it’s easy to spot tons of bad email coming from a block of IPs or a given geographical area. With a botnet, no machine sends more than a few requests at a time, and the IP addresses can vary. With bots around the world, a spam network can send millions to billions of emails a day — sometimes packing in the very same malware that generated them in the first place.
Not all botnet masters want to do the dirty work on their own, either. With sufficiently large botnets, you’ll often find that the owners allow others to use them, for a price. By some estimates, botnet owners can make hundreds of thousands of dollars a year leasing their enslaved networks to spammers, identity thieves, and other unsavory individuals. With such an easy and anonymous way to engage in illicit activity on the Web, it’s no wonder that these networks have grown in size, scope, and popularity over the last two decades.
How botnets communicate
So how does all this happen? With botnets sending spam, taking down websites, and overall being disruptive, you’re probably wondering how the botmasters control their networks. These infected devices can only do what they’re told, after all; from time to time, the owner of the bots might want to change their target, alter their programming, or even take the network dormant.
All of this happens through a process known as “command and control,” or C&C. There are several methods that hackers use for command and control, and while some are easier to detect than others, their methodologies are always evolving. To succeed in disrupting or bringing down a botnet, it’s almost always necessary for security teams to figure out how the bots are get their orders. Over the past decade or so since the first botnets arrived on the scene, these methods have undergone some substantial changes.
The most basic way for bots to “phone home” to their boss is by using IRC, or Internet Relay Chat, a protocol that some of our older listeners may know well. The hacker sets up one or several IRC servers that bots then communicate with, sending back very low-bandwidth messages that are less likely to draw attention from a user or the system. These messages may report status, while the botmaster may issue new commands to the botnet. IRC command and control is cheap, effective, and allows for rapid channel-switching — like jumping between different chat rooms every few minutes. This method allows for continuous instruction while avoiding detection.
That said, IRC is a weak method for C&C today, and it is straightforward for researchers to cut off IRC-controlled botnets after identifying the servers in question. Something as simple as keyword blocking, or cutting off access to the IRC port on the infect machines, can render them completely inaccessible to the botmaster. As a result, many hackers have moved on to other, more sophisticated methods for communication with their electronic slaves.
Bots might disguise their communications as HTTPS traffic, usually to the controlling server; because it looks like regular web traffic, it’s not always easy for the good guys to pick out the bad traffic and filter it out. A similar, but even more subtle method, involves the actual TCP network packets sent off your machine. By altering the “header” information of each packet just a small amount, bots can send encoded messages back to their masters and vice versa. Sometimes there’s nothing special about the way the bots communicate — they just send basic requests straight to the bad guy’s servers.
Most local anti-malware solutions won’t think to look in this space for illicit commands. Thankfully, outbound network security is improving by leaps and bounds, and strict rules about what packets contain can help to mitigate this threat. Called egress filtering—packets that don’t look right aren’t allowed to exit onto the Internet.
On the bot herder’s side, their C&C server often features a customized control panel. A hacker might be able to see, at a glance, how many machines are active on the network and whether any of them have exfiltrated desirable data. They also use these control panels to send updates or make changes to the bot malware; for example, when renting use to another customer, a hacker might receive payment to drop a keylogger on machines in a given area. Through his control panel, he can send a new malware dropper to the devices in question. That’s just one example, of course — they could be sending spam or just searching for new machines to infect.
Sometimes, C&C takes a more oblique route to a user’s machine, rather than communicating directly with a server. Bots might leverage a P2P—or peer-to-peer—network made from other zombie machines. Some bots that receive instructions then work to locate other infected computers to pass along the instructions. Some malware authors have even taken to using social media to issue commands to bots. How?
The easiest example we can use is Twitter. Here, a hacker sets up an account and directs bots to routinely access the syndication feed for a Twitter account they also control. From there, they tweet encoded commands that look like gibberish to anyone observing. As the bots check in with Twitter, they see the new commands inside the tweets and change their behavior accordingly. They may act as an intermediary step, directing bots to new C&C server domains to avoid detection or when their old servers go down.
A look at some of the biggest botnets
Altogether, the details we’ve been discussing so far should give you a good view on botnets and how they work. What are they like out in the wild, though? To answer that question, we can look both at some of the biggest botnets ever assembled as well as some smaller networks that still managed to be incredibly disruptive. Mirai, for example, is one we talk about a lot, and it’d be easy to think it must have been among the largest in history. That’s not the case, though; as a matter of fact, the Mirai botnet encompassed fewer than a million compromised devices.
Even several hundred thousand machines taking orders from a botmaster can wreak havoc, though, as we saw when Mirai was commanded to flood DNS provider Dyn. With hijacked baby monitors and web-connected security cameras, major websites went offline. Users around the world found their daily web browsing disrupted and soon learned a botnet was to blame. While it’s not causing more major and visible problems right now, Mirai is still out there, and there have even been some new variants of the core malware popping up over recent months.
What was the biggest botnet ever? For that, we’ll need to jump back to 2009 and 2010, when a botnet known as Bredolab rose to infect, by some estimates, nearly 30 million computers. Other botnet masters have built networks that come close to Bredolab’s widespread infections, but none have yet definitively beaten its numbers.
Users were first infected primarily through malicious email attachments; users often received emails claiming they had been given an iTunes gift certificate, or that they had missed delivery on a package from UPS. Once downloaded, the Trojan dumped onto the machine communicated with its C&C server to download a vast range of additional malware.
From keyloggers to fake antivirus software and more, Bredolab pushed tons of dangerous data onto infected machines — and all for money. The master of the Bredolab botnet farmed out portions of it to customers paying to rent the botnet, allowing them to send their own malware to infected machines. At its peak, Bredolab could send out more than three and a half billion viral spam messages every day!
Ultimately, authorities seized the central C&C servers for Bredolab and derailed its rise. However, many machines likely remained infected for years afterward, and some continued to remain under the control of far-flung servers in Russia. Even so, it was a quick and efficient end to the biggest botnet ever. You don’t need to be the biggest or even the baddest to cause concern, however, and that’s what we saw when the Conficker worm spread like wildfire around the globe.
The malware itself was advanced and exploited Windows vulnerabilities to entrench itself onto an infected system. Its extreme virulence led it to infect millions of PCs. Today, estimates of the Conficker botnet’s size range from a few million to nearly 10 million, with a capacity to potentially send 10 billion spam emails in a day. Since its arrival, researchers have worked hard to limit the botmaster’s ability to exploit the network. After successfully hampering Conficker’s ability to receive new instructions from its C&C servers, the authors switched to using a custom peer to peer network.
Almost ten years later, Conficker is still around, and researchers continue to watch and examine its evolution. So far, the full might of the botnet has never been unleashed on any target that we know of, and with a dedicated group fighting back against it, we can be hopeful that such a day will never come.
As interesting—and perhaps intimidating—as big botnets can be, you don’t need millions of machines to build a botnet worth renting out to other cyber criminals. Create something that enslaves any reasonable number of computers, and the bad guys can still do what they want — and maybe even avoid detection in the process. After all, the bigger a botnet grows, the more intense scrutiny it receives. For many, it’s better to fly under the radar. For that reason, the efforts to push back against bot herders is important.
How security researchers fight back against botnets
Obviously, we aren’t powerless to fight back against the creation and maintenance of botnets. The first line of defense is obvious enough: prevent the infections from occurring in the first place. That’s not always possible, especially when malware relies on obscure or zero-day exploits to spread rapidly. Once someone has established a botnet and begins to use it (or rent it out), that’s when the second line of defense comes into play: the hard work of white-hat hackers and security researchers to figure out a way to cut off the botmaster’s access to his zombie machines. How do we do that?
There are a few ways to disrupt a botnet, but the most popular and effective methods usually revolve around neutralizing the command and control servers or blocking their ability to communicate with individual bots. One example: we mentioned earlier that when a botnet uses IRC, blocking connections or closing the affected ports can help. Identifying bot traffic before it leaves the user’s system is also a handy method.
Unfortunately, these only help with a few individual machines at a time. To make a bigger breakthrough and neutralize a botnet’s ability to push more malware, researchers need a more direct way of interdicting the command and control apparatus of a botnet. One of the best ways for the good guys to do this, and to learn more about the malware and its tools in the process, is by pretending to be the C&C server. Sometimes called “sinkholing,” the basic idea is to stand in for the botmaster by masquerading as the correct server. Sinkholing can happen in a couple of ways.
First, researchers might notice that a botnet doesn’t have its C&C server set up yet. Sure, this is a rookie mistake, but even hackers slip up sometimes. Though it wasn’t a botnet, the WannaCry ransomware was killed with this method after security pros discovered that there was a “killswitch” domain hidden inside the code. By capturing the domain and setting up a server to collect data for analysis, we can effectively neuter the botnet’s ability to cause problems.
Second, researchers might be able to sinkhole a domain thanks to a friendly ISP. While many hackers set up botnet domains with registrars unlikely to shut off their service, concrete proof can stir some providers to action. In this case, it’s as simple as replacing the illegitimate server with one controlled by researchers. Now the botnet phones home to the server it expects, but it receives nothing in return.
The malware just dumps all its data right into the hands of researchers. When enough data has fallen into their “sinkhole,” they just kill the server. Sinkholing can cut off large swaths of the net from the botmaster, or even leave the entire network unable to communicate. While not as permanent a solution as removing the offending malware from specific machines, it gets the job done. Even the FBI has used this solution in the past to kill botnets or at least render them mostly inert.
In some cases, the reverse engineering work done via sinkholing or by examining a piece of the botnet malware will reveal built-in kill codes that can shut down the botnet. Even cyber criminals are wary of creating a network that grows out of control. That’s not to mention the fact that other bad guys might try to steal and take over a well-established botnet! For that reason, hackers sometimes encode these shutdown commands to allow them greater control over their networks. When researchers uncover these, they can impersonate the C&C server and tell the malware to stop functioning.
Despite all these efforts, we still see new botnets arriving on the scene and growing larger every year; there’s no doubt that researchers and hackers are locked in a kind of “arms race” over their implementation and mitigation. While the average home desktop or laptop user does not have too much to worry about, as botters predominantly target enterprise-level systems or other insecure devices, there’s a clear need to remain aware of the threat. Even as Macs remain relatively immune to botnet-building malware, we know how quickly that can change — so remember to sweep your machine regularly to keep it from becoming zombified!
That’s it for another episode of The Checklist. Come back next week as we investigate another security topic!
