Welcome to the second in our series of blog posts on malware evolution and its impact on Incident Response. In our first installment we focused on how modern malware has evolved and why it is essential for us as Incident Responders to be prepared for what our adversaries are operating with. We considered some examples and discussed attacker’s motivations behind malware payloads and the impact on victims.
Today’s topic is dedicated entirely to bot-related matters, where we will examine botnet infrastructure. Botnets are considered by some to be the Internet offender’s weapon of choice. Before we delve directly into the computer criminal’s cyber-arsenal, it is important to understand what bots and botnets are and how they work. The subject of bots opens up a whole new glossary of terms and abbreviations, which we will describe and demystify.
A bot is, in simple terms, an infected computer under the remote control of a malevolent computer user. When a computer is infected with bot malware it unwittingly and covertly joins a network of similarly infected machines, often hundreds or even thousands in number, forming what is called a botnet, a shortening of Robot Network. The bots remotely connect to and are controlled by a rendezvous point, commonly called the Command and Control server (sometimes abbreviated to C&C or C2). This connection may be persistent or intermittent and may use one or more Internet network protocols in order to communicate.
The cybercriminals, who control botnets, are referred to as Bot Herders or Bot Masters. When a so-called Bot Herder logs into the C&C infrastructure he or she is able to control all of the infected computers within the botnet and operate a distributed network army behind the relative safety of the C&C. The bots, also sometimes referred to as zombies, operate completely at the will of their Bot Herder. With the use of faster processors and more Random Access Memory (RAM) in modern computers, machines with malware infestations that are not properly configured with security software are able to exist undetected. Sometimes Bot Herders do not connect directly to the C&C; they use proxied connections in an attempt to distance themselves from further from their captive computers.
A simple botnet topography is a centralised client server/model where the bots report and connect to a single C&C server. Imagine, if you like, a bicycle wheel, the C&C is the hub and at the end of each spoke is a bot. When the C&C server is disconnected from the Internet the botnet fails, as the bots have no rendezvous-point to connect to. If the command and control server reconnects to the Internet the bots will re-join the C&C and the botnet will establish itself again.
In cases where the bots are configured to connect to a hostname for the C&C connection, for example bad-host.com, the bots will attempt to connect to that command and control server as long as the server resolving to that hostname is connected to the Internet. If the rendezvous-point configuration contains an IP address the bot will attempt to connect to the computer assigned with that IP address only.
As Incident Responders the scenarios where a single C&C server is used creates an ideal disruption opportunity for us and represents a single point of failure for the cybercriminal. If the C&C can be taken offline the bots are no longer under the control of the Bot Herder and we can focus on containing and mitigating the incident; the head is cut off of the serpent. If only life were so simple, in what has now become a cyber-arms race, as one criminal ploy is foiled another technique, created to avoid disruption, bubbles to the surface.
As contingency planning modern botnet malware often utilises a number of domains or IP addresses to connect to. Others are configured to connect to a series of proxy servers, which afford the C&C a layer of protection. The redacted image below shows a computer infected with bot malware attempting to unsuccessfully connect to a number of IP addresses used as web proxy servers every ten seconds. Once established the bots transmit data to the C&C, which remains hidden behind the proxy layer.
The first botnets used Internet Relay Chat (IRC) protocol for communications, PrettyPark.Worm[1] being an early example. These connections were persistent and the nature of IRC made them highly scalable, configurable and controllable. Following on from IRC, hypertext transfer protocol (HTTP) was and still is used as a C&C communication protocol, Trojan.Zbot[2] being a notable illustration. Malicious connections between bot and C&Cs were able to exist within legitimate web traffic making illicit communications more difficult to detect, IRC traffic being more readily identified on a network. HTTP botnet infrastructure can be used as either a relay mechanism, as shown above, to serve updates and supplementary resources, or as a direct Command and Control server.
There are other more complex Botnet C&C models, Peer-to-Peer (P2P) infrastructure presents a decentralised meshed topography and as such is more far challenging to investigate and dismantle. Upon execution infected host computers will attempt to establish communication with their peers. The redacted image below shows a PC infected with Trojan.Peacomm[3] attempting to publicize its presence to a number of peers using the eDonkey/Overnet Protocol. In this instance the malware opens and listens on port UDP/4000 for connections.
In P2P botnets there is no obvious C&C component to target in order to tackle the infrastructure. Network dialogue instructions contained within P2P botnet malware often include peer coordination as well as C&C communications. Other methodologies are now commonly incorporated into modern botnet configuration including Domain Name System (DNS) abuse and encryption methodologies.
So, here we are at the end of our whistle stop tour of botnet infrastructure. As you’ve most likely realised, the subject of bots and botnets is vast. The fundamental point to remember is that botnets require a network to exist.
We have now built a foundation of understanding on botnets and how we as Incident Responders can begin to investigate them. To continue our journey in our next instalment we will examine botnet payloads.
