A botnet is a network of compromised devices that can act on remotely coordinated instructions. Command and control (C2) can be centralized, as in the illustration, or distributed through peer-to-peer designs. Each infected machine is a “bot,” the person controlling them is the “bot herder,” and the channel through which commands are issued is called command and control (C2). Together they form a distributed platform that can be pointed at any target the operator chooses.
Table of Contents
Botnets are usually described from the target’s perspective the site knocked offline, the accounts drained, the inbox flooded. But there is a second victim in every botnet, and it is the one this article is written for: the operator whose address space the bots are running on. When machines on your IP addresses are compromised, the attacker is not just using someone else’s computing power. They are spending your IP reputation to run their operation. Spam, scanning, and attack traffic leave your addresses, get attributed to your addresses, and produce the blocklist entries and abuse reports that follow your addresses long after the malware is cleaned off the machine.
That asymmetry is the reason botnets deserve attention from anyone responsible for public IPv4 space, not just from security teams. This article explains what botnets are and how they work, how their activity can affect individual addresses or wider reputation groupings, why botnet traffic is unusually hard to attribute, how to recognise compromised hosts on your own space, and how responsibility divides when the space is leased.
What is a Botnet
A malicious botnet coordinates compromised devices; it does not require one controller, one command server, or one visible traffic pattern. The individual machines continue to function normally from their owners’ point of view, which is precisely the design goal a bot that announces itself gets cleaned.
Three terms carry the concept:
- Bot. A single compromised device running the malicious software. It can be a server, a desktop, a router, a camera, or any other connected device with enough capability to be useful.
- Bot herder (or bot master). The operator who controls the collection and decides what it does.
- Command and control (C2). The communication channel through which instructions reach the bots and results return. C2 is what turns a scattered set of unrelated infections into a coordinated system — without it, they are just individually compromised machines.
Scale varies enormously. Some botnets consist of a few hundred machines; documented cases have reached hundreds of thousands or more. What makes them dangerous is not any individual bot’s capability but the aggregate: thousands of geographically dispersed machines, on thousands of different networks, acting in concert.
How Do Botnets Work?
A botnet operates in three stages: infection, control, and coordinated action.
Infection. Malware reaches a device and installs itself, typically designed to persist quietly through reboots and to avoid producing symptoms the owner would notice. Modern bot malware often installs additional components over time rather than arriving as a single complete package.
Control. The infected machine reaches out to command-and-control infrastructure to register itself and await instructions. Repeated connections can be a useful signal, but legitimate services also make them and malicious traffic may be encrypted or irregular. Correlate network observations with endpoint evidence.
Coordinated action. The operator issues instructions, and some or all of the bots act simultaneously: sending traffic at a target, transmitting spam, relaying connections, scanning address ranges, or harvesting data. The same collection can be repurposed for different activities on different days.
One structural feature matters for the rest of this article: the bots do the acting, so the traffic carries their addresses not the operator’s. The bot herder may be anywhere; what the targets and the reputation systems see is the address of a compromised machine sitting on someone’s legitimate network. That is the entire point of the architecture, and it is why the operator whose space hosts the bot absorbs the consequences.
How Devices Get Recruited
Devices join botnets through the same weaknesses that lead to any compromise and awareness of the common routes is what makes prevention practical. The recurring ones, described at the awareness level:
- Unpatched vulnerabilities. Exploitation of known flaws in operating systems, applications, and network-facing services. Unmaintained systems are disproportionately represented in botnets for the obvious reason.
- Weak or default credentials on exposed services. Automated attempts against Internet-facing login interfaces — SSH, RDP, admin panels, and similar succeed regularly where credentials are weak, reused, or left at defaults.
- Phishing and malicious attachments. The classic user-facing route, delivering malware through email links and files.
- Drive-by downloads. Malware installed through compromised or malicious websites without deliberate user action.
- IoT and embedded devices with default settings. Cameras, routers, and similar devices shipped with default credentials and rarely updated have become a major recruitment pool, since they are numerous, always on, and seldom monitored.
This is also the right place to clear up a common confusion: brute-force attacks and botnets are not the same thing. A brute-force attack is a method systematically trying credentials until one works. A botnet is infrastructure a network of compromised machines. They intersect because botnets are frequently used to carry out distributed credential attacks (spreading attempts across many bots so no single source looks abnormal), and because successful credential guessing is one way machines get recruited into botnets. But neither requires the other.
What Botnets Are Used For
Botnets are general-purpose attack infrastructure, which is why the same collection can be rented out for entirely different purposes. The main uses:
- DDoS attacks. The best-known application: thousands of bots directing traffic at one target simultaneously. The distributed nature is what makes these attacks difficult to filter by source, and it shapes the defences described in our guide to DDoS mitigation.
- Spam distribution. Sending unsolicited email from many compromised hosts rather than from identifiable infrastructure — historically one of the highest-volume uses.
- Credential and data theft. Harvesting passwords, financial details, and other data from infected machines.
- Distributed credential attacks. Spreading login attempts across many bots so each source stays below detection thresholds.
- Scanning and reconnaissance. Systematically probing address ranges to find further vulnerable hosts — both to expand the botnet and to build target lists.
- Proxy relays. Using compromised hosts to relay the operator’s own traffic, concealing its true origin behind a legitimate machine’s address.
- Click fraud and cryptomining. Monetising the aggregate — generating fraudulent ad traffic, or using the collective processing power of infected devices without their owners’ knowledge.
Botnets are also commercialised. Access is rented out to third parties who want attack capability without building their own infrastructure — a service model that lowers the technical barrier to launching attacks and helps explain why botnet activity persists as a background constant rather than fading as defences improve.
Why Botnets Damage Your IP Reputation
Observed abuse can affect an individual IP address, a shared egress address, or a wider prefix, depending on the receiving service and its listing criteria. A report is evidence to investigate, not proof that every host in a range is infected. The address-space operator can face consequences alongside the attack target; some restrictions can persist after remediation.
The mechanism has three parts:
First, attribution follows the address. When a bot sends spam or attacks a target, the recipient sees a source IP address belonging to your space. Blocklist operators, reputation systems, and mail providers record it against that address, and abuse reports are directed to the abuse contact registered for the block a process covered in detail in our guide to network abuse and handling abuse reports. Nothing in this chain identifies the actual operator; the address is what gets recorded.
Second, evasion tactics spread the damage across ranges. Botnet operators deliberately keep per-host activity low to stay under detection thresholds — sending a smaller volume of spam from each of a larger number of compromised hosts, rather than a high volume from a few. Research on spam-emitting botnets documents exactly this shift: reducing volume per compromised host specifically to evade anti-spam detection. The consequence for operators is that botnet abuse tends to touch many addresses lightly rather than one address heavily, which is how a single compromise event can degrade the standing of a whole neighbourhood of addresses — including ones that were never infected.
Third, reputation recovers slowly. Cleaning the infected machine stops the emission but does not clear the record. Removal and expiry rules differ by list. Follow the affected provider's current instructions after remediation; neither a fixed recovery time nor universal delivery can be promised — the dynamics described in our guide to IP address reputation.
The practical framing: incident response and reputation recovery are separate workstreams with case-specific timescales, on an asset every service you run depends on.
Why Botnet Traffic Is Hard to Attribute
Several properties of modern addressing make botnet activity unusually difficult to trace back to specific machines which complicates both defence and dispute.
Dynamic address churn. Infected hosts on consumer connections change addresses constantly as ISPs reassign them. The landmark academic analysis of the Torpig botnet found this effect so pronounced that infected hosts appeared with a new address almost every time they connected, with one host observed changing addresses 694 times in ten days — and the same machine appearing across different /16 subnets within the same autonomous system. The consequence is that address-based counting massively overstates botnet size, and that “the address that misbehaved yesterday” may belong to an entirely different subscriber today.
Shared addresses. Where carriers place many subscribers behind one public address the CGNAT arrangement used by many providers, one subscriber's abuse can affect other users of that address. An outside observer cannot identify a particular internal host from the public IP alone. Correlating source IP, source port, transport protocol and an accurate timestamp with the provider's matching assignment or NAT logs may narrow attribution; it still does not identify the person responsible.
Deliberate origin concealment. Bots are used as relays precisely so the operator’s own traffic appears to come from a compromised host. Separately, attackers may forge source addresses entirely, as described in our guide to IP spoofing in which case your addresses can appear in attack traffic that never touched your network at all.
For an operator, the implication is that being flagged is not proof of local compromise, and being clean is not proof of innocence in the eyes of a reputation system. Both directions require evidence — which is why retaining traffic records matters as much for defending your space as for investigating it.
Signs Your Network Hosts Compromised Machines
Detection can combine endpoint alerts, process and authentication evidence, network observations, and abuse reports. No single signal proves compromise or its absence. The signals worth watching:
- Unexplained outbound traffic volume. Sustained outbound activity that does not match the system’s function — particularly from servers with predictable normal patterns.
- Unexpected mail volume. Outbound SMTP from hosts that should not be sending mail, or a jump in volume from those that should.
- Outbound scanning. Your addresses probing wide ranges of external hosts — a strong indicator of either compromise or misuse.
- Repeated patterned contact with unfamiliar external infrastructure. The check-in behaviour of C2 communication tends to be regular and machine-like in a way ordinary traffic is not.
- Abuse reports. Often the first notification an operator receives, which is why a monitored, working abuse contact is a detection mechanism as much as an administrative obligation.
- Blocklist appearances. Discovering your addresses listed, especially without an obvious cause, warrants investigating for compromise rather than assuming an error.
- Resource anomalies. Unexplained CPU load can indicate cryptomining components, which are among the more detectable payloads for exactly this reason.
Use inbound, outbound and endpoint evidence together. Preserve relevant timestamps and records with access controls and a defined retention period; do not collect unrelated personal data simply because an address was reported.
Botnets and Leased IPv4: Shared Responsibility
Botnet compromise is one reason leased IPv4 needs a documented abuse-response handoff. Agree who receives reports, who has authority to contain affected systems, and who coordinates remediation.
Responsibilities depend on the service arrangement. The lessee, hosting provider or managed-service team may control the host or network; remediation must be performed by an authorized operator. Report delivery depends on the published contacts and the reporting channel. Where host control, address management and abuse handling are split between organizations, coordinate their evidence and actions instead of assuming one party can resolve the incident alone.
What each side owes, in practice:
- The lessee secures their systems, monitors outbound traffic, acts promptly on forwarded reports, and recognises that the reputation being damaged is a shared asset attached to addresses they will keep using.
- The holder or lessor maintains a monitored abuse contact, relays reports quickly and clearly, monitors the reputation of the space, and escalates where remediation does not happen.
This is why abuse and compromise handling belongs on the pre-lease verification list alongside routing authorization and reverse DNS. The questions are concrete: who receives abuse reports, how fast are they relayed and through what channel, who is expected to respond, what are the escalation terms if abuse continues, and will the lessor assist with delisting afterward? The written scope of a IPv4 leasing arrangement should name these responsibilities. Address leasing alone does not provide endpoint security or guarantee removal from third-party blocklists. An informal one leaves the lessee unaware of reports they never see while the block degrades. The same diligence applies when you Buy IPv4 addresses: a block’s history of botnet-related abuse is part of the reputation you inherit.
Preventing Your Systems From Joining a Botnet
The measures that keep systems out of botnets are unglamorous and well established:
- Patch promptly. Known, unpatched vulnerabilities in Internet-facing services are the most consistently exploited route.
- Eliminate weak and default credentials. Especially on anything exposed to the Internet, and especially on embedded and IoT devices where defaults often survive deployment.
- Restrict exposed management interfaces. SSH, RDP, and admin panels should not be openly reachable from the entire Internet where an allowlist, VPN, or bastion arrangement is possible.
- Filter outbound source addresses. Source-address validation can reject traffic outside the prefixes authorized on a connection. Prefix filtering does not stop spoofing within an allowed prefix, malware using its assigned address, or botnet command and control.
- Apply outbound rate limits. Appropriate mail and connection limits can reduce some abuse, but do not contain every payload or replace isolation and remediation. Check the effect on legitimate services.
- Monitor outbound traffic. Correlate outbound anomalies with endpoint and inbound evidence; absence of an alert is not proof that a host is clean.
- Audit exposed services. Know what is reachable from the Internet on your space, and close what does not need to be.
Practical Checklist
- Monitor outbound traffic for volume anomalies, unexpected mail, and scanning from your space.
- Keep Internet-facing systems patched, with a defined process rather than ad-hoc updates.
- Eliminate default and weak credentials, particularly on exposed and embedded devices.
- Restrict management interfaces rather than exposing them to the open Internet.
- Implement outbound source-address filtering and outbound rate limits.
- Maintain a monitored abuse contact — it is often your first compromise notification.
- Monitor the reputation of your address space, including ranges not currently in heavy use.
- Retain traffic records sufficient to establish what did and did not originate from your network.
- Have a defined response: isolate, remediate, find the entry point, answer reports, pursue delisting.
- For leased space, confirm in writing how abuse reports are relayed and who responds.
- After any incident, check surrounding addresses for reputation impact and further compromise.
Final Thoughts
A botnet is a network of compromised machines capable of acting on remotely coordinated instructions, coordinated through command-and-control infrastructure and used for DDoS attacks, spam, credential theft, scanning, proxying, fraud, and mining — often rented out to others who want attack capability without building it. Devices are recruited through unpatched vulnerabilities, weak credentials on exposed services, phishing, drive-by downloads, and unmaintained IoT defaults, and the malware is designed to persist without giving the owner any obvious sign.
For anyone operating public IPv4 space, the important shift in perspective is that a botnet has two victims: the target it attacks and the network whose addresses it attacks from. Botnet traffic carries your addresses, so it accrues to your reputation — and because operators deliberately spread activity thinly across many hosts to evade detection, the reputation impact may cover individual addresses or wider groupings, depending on the receiving service, while dynamic address churn and shared carrier addresses make precise attribution genuinely difficult. The defences follow from that: watch outbound traffic, keep exposed systems patched and credentialed properly, filter and rate-limit what leaves your network, keep a monitored abuse contact, and respond fast when something does slip through. These controls reduce risk but do not guarantee containment or reputation recovery. Investigate each report, verify remediation, and follow the affected services' current procedures.
Frequently Asked Questions
What is a Botnet in simple terms?
A botnet is a group of compromised devices capable of acting on remotely coordinated instructions, using centralized or distributed command and control. The owners usually have no idea, and the attacker uses the combined machines to send spam, launch attacks, steal data, or relay traffic.
What is a bot herder?
A bot herder, also called a bot master, is the person or group controlling a botnet. They issue instructions to the infected machines through command-and-control infrastructure and decide what the botnet is used for — or rent that capability out to others.
Are botnets and brute-force attacks the same thing?
No. A brute-force attack is a method — systematically trying credentials until one works. A botnet is infrastructure — a network of compromised machines. They overlap because botnets are often used to run distributed credential attacks, and because successful credential guessing is one way machines get recruited into botnets, but neither requires the other.
What are botnets used for?
DDoS attacks, spam distribution, credential and data theft, distributed login attacks, scanning for further vulnerable hosts, relaying traffic to conceal the attacker’s origin, click fraud, and cryptomining. Access to botnets is also commonly rented out to other criminals.
Does botnet activity affect my IP reputation?
It can. Receiving services may restrict an individual address, shared egress address or wider prefix based on their own evidence and criteria. Verify which service, address scope and observation time are involved; a listing does not prove that every nearby host is compromised or determine a universal recovery period.
Can leased IP addresses be affected by botnet activity?
Yes. Reports and host control may belong to different teams. Name the authorized host or network operator, reporting contacts, response and escalation duties, and any agreed delisting assistance in the service scope. Leasing an address does not itself secure the systems using it.
How do I recover IP reputation after botnet abuse?
Investigate the report and remediate any confirmed compromise or misuse. Respond with relevant evidence, follow each affected list's removal or expiry procedure, and retest the intended service. Check other potentially affected addresses without assuming they are infected. There is no guaranteed recovery time or universal acceptance after removal.
Further reading: IETF bot detection and remediation guidance, logging for shared-address attribution, source-address filtering and its limits, and Spamhaus remediation and removal procedures.
