InfectBot: An Infection-Centric Approach

• InfectBot is an infection-centered analytic paradigm that unifies diverse methods for detecting malware, analyzing encrypted payloads, and mapping infection structures.
• It employs host-based behavioral detection, API hooking with statistical correlation, and collaborative network watermarking to identify botnet activities.
• The approach extends to IoT devices and multi-robot systems, enabling rapid remediation and coordinated defenses against evolving infection strategies.

In the works gathered under this label, InfectBot denotes an infection-centered perspective on malicious automation rather than a single canonical artifact. The term is used for host-based behavioral detection of a single infected machine, recovery of encrypted malware command-and-control payloads from process memory, structural analysis of worm-created infection trees, collaborative network watermarking of IRC botnets, early-stage IoT propagation detection, Mirai remediation by a manufacturer-operated benign implant, and, in an embodied-AI setting, propagation of unsafe actions across LLM-controlled robot teams (Al-Hammadi et al., 2010, McLaren et al., 2019, Huang et al., 15 May 2026). This semantic breadth is itself technically significant: the unifying object is not merely a bot, but the process of infection, coordination, propagation, or compromise.

1. Terminological scope and conceptual unification

The literature represented here uses InfectBot in several distinct but related senses. In some cases it refers to host-based behavioral bot detection on a single machine; in others, to discovering encrypted malware payloads through memory inspection; elsewhere, to infection-topology-aware bot exposure, IRC botnet watermarking, IoT propagation detection, Mirai expulsion, or multi-robot compromise propagation (Al-Hammadi et al., 2010, McLaren et al., 2019, Wang et al., 2010, Houmansadr et al., 2012, Famera et al., 2023, Cao et al., 2017, Huang et al., 15 May 2026).

Usage domain	Core mechanism	Source
Single-host bot detection	API monitoring and behavioral correlation	(Al-Hammadi et al., 2010)
Host immune-inspired detection	DCA with PAMP, DS, SS, MCAV, MAC	(Al-Hammadi et al., 2010)
Infection-structure detection	Tree statistics and targeted inspection	(Wang et al., 2010)
IRC botnet exposure	Collaborative timing watermark	(Houmansadr et al., 2012)
Encrypted malware analysis	Memory inspection for keys and IVs	(McLaren et al., 2019)
IoT propagation detection	Cross-device federated IDS	(Famera et al., 2023)
Mirai remediation	“white” Mirai / virus expeller	(Cao et al., 2017)
Multi-robot unsafe propagation	Single-robot compromise and peer relay	(Huang et al., 15 May 2026)

A common misconception is that InfectBot must designate a specific bot family or a single detector. The corpus instead shows a recurring emphasis on infection observability: keyboard interception combined with file writes and exfiltration, flow similarity among infected hosts, key material resident in memory during TLS, server-side Telnet loader behavior, early IoT propagation signals, or peer-to-peer policy drift among robots. This suggests that InfectBot is best understood as an infection-oriented analytic lens spanning host, network, cloud-loader, IoT, and embodied multi-agent settings.

2. Host-resident infection detection on individual machines

A foundational line of work treats InfectBot as host-based behavioral detection of a single bot. In “Detecting Bots Based on Keylogging Activities,” the monitored behaviors are grouped into CommFunc (socket, send, recv, sendto, recvfrom, IcmpSendEcho), FileAccess (CreateFile, OpenFile, ReadFile, WriteFile), and KeyboardState (GetKeyboardState, GetAsyncKeyState, GetKeyNameText, keybd_event). These calls are captured by a hooking program that injects into running processes and intercepts API calls by modifying the Import Address Table. Detection is not based on any single call; instead, the method correlates the frequency of these behaviors over a 10-second time window using Spearman’s Rank Correlation, with $T = 0.5$ as the high/low threshold. If keyboard-state calls co-occur with both communication and file-access correlations above $T$, the result is Strong detection (Al-Hammadi et al., 2010).

The Spybot case study makes the behavioral logic concrete. On a small virtual IRC network in VMware, experiments ran for 15 minutes on an infected host connected to IRC. The clearest malicious pattern arose in E4.2, where short typing caused high correlation between GetAsyncKeyState and Bytes Sent, and between GetAsyncKeyState and WriteFile; this was the strongest evidence of active keylogging plus exfiltration. By contrast, E1 and E2 showed that traffic alone may be misleading, because idle periods and periodic IRC activity can inflate correlation through shared zero-valued intervals. The method’s stated limitations are equally important: it uses user-mode API hooking, does not capture kernel-level calls, focuses on keylogging bots, and can be evaded if a botmaster inserts random delays (Al-Hammadi et al., 2010).

A biologically inspired variant appears in “DCA for Bot Detection,” where the Dendritic Cell Algorithm correlates process-level antigen with three signal categories: PAMP, Danger Signal, and Safe Signal. Output signals are csm, semi, and mat; cells migrate when the costimulatory signal exceeds a migration threshold, and collected antigen is labeled as safe or dangerous according to semi-mature versus mature output. The resulting anomaly scores are MCAV and the support-adjusted MAC, with the latter introduced to reduce false positives when antigen counts are small. In controlled experiments with spybot, sdbot, and IceChat, the paper reports that the DCA was successful in detecting the bot without responding to normally running programs, while also showing that weight selection materially affects performance (Al-Hammadi et al., 2010).

An enterprise-oriented extension places a standalone algorithm on each node and triggers a network algorithm only when local suspicion becomes high. The host-side detector monitors response time, output-to-input traffic ratio, number of active connections, ports, continuous attempts for connection setup, UDP work weight, and API/log behavior, then computes a suspicion value as a weighted average of the monitored parameters. This architecture preserves the host-centric intuition of earlier work while coupling it to later enterprise-wide confirmation and signature generation (Thakur et al., 2013).

3. Network-centric and structural views of infection

Another strand of InfectBot research shifts the unit of analysis from a single host to network conversations and infection structure. “Characterizing Internet Worm Infection Structure” models worm recruitment as a directed infection tree rooted at patient zero. The paper derives that the number of children is asymptotically geometric with parameter 0.5, so about 50% of infected hosts are leaves and over 98% have no more than five children. Generation follows closely a Poisson distribution, and the average path length grows approximately logarithmically with the total number of infected hosts. These regularities motivate targeted detection: instead of sampling nodes uniformly, defenders examine hosts with the largest number of children. In simulation, when only 3.125% of nodes are examined, targeted detection reveals 22.36% of bots, versus 9.10% for random detection (Wang et al., 2010).

For centralized IRC botnets, “BotMosaic” proposes a collaborative network watermark inserted into the aggregate traffic of multiple captured bots. Time is divided into $2\ell$ non-overlapping intervals of length $T$, randomly assigned into HI-LO interval pairs known only through a secret key. Detection relies on interval-count differences

$A(i) = N(HI_i) - N(LO_i),$

with a pair marked detected if $A(i) > n$, and a flow declared watermarked if the number of detected pairs $n_c \ge \theta$. Because the watermark is inserted collaboratively across $R$ captured bots, it survives mixing with traffic from real bots and remains content agnostic, including on encrypted IRC traffic. In simulations with $T = 500$ ms, $\ell = 64$, and $T$0, the watermark could be inserted into a 64-second botmaster connection with COER on the order of $T$1; PlanetLab experiments detected the watermark in as little as 32 seconds on the botmaster path (Houmansadr et al., 2012).

A different network view appears in the IDS-driven multi-phase IRC botnet and botnet behavior detection model. Using Snort alerts, filtering, spatial-temporal similarity analysis, clustering, and correlation across phases, the model tracks a host from suspicious IRC connection, through IRC PRIVMSG responses, to outbound attack behavior. It explicitly distinguishes coherent and non-coherent modes, handles both standard ports 6661–6668 and non-standard IRC ports, and reports not merely that a host is infected, but also whether it is only issuing C&C replies or also participating in attack activity. Across virtual-network scenarios, the paper reports 100% detection accuracy for infected IRC bots and 100% pass-through of legitimate IRC messages, while also noting some false positives in botnet behavior detection on one DARPA trace (Awadi et al., 2015).

4. Encrypted channels, memory artefacts, and loader infrastructure

Infection analysis becomes more demanding when command-and-control is encrypted or when infection logic is delegated to server-side infrastructure. “Discovering Encrypted Bot and Ransomware Payloads Through Memory Inspection Without A Priori Knowledge” addresses Windows malware clients that use TLS and Microsoft cryptographic libraries. The method captures malware process memory, searches for keys, IVs, and key blocks, and uses those artefacts to decrypt live TLS communications without prior knowledge of the malware family or its custom protocol. For AES-GCM, the approach exploits the explicit IV present in TLS Application Data, then searches memory for nearby implicit IV and key-block material. Because generic TLS memory matching produced very large candidate sets, the paper adds Windows-library-specific anchors, notably the ASCII markers 3LLS and KSSM, together with entropy-based prioritization using thresholds 1.5 for IVsize entropy and 4.5 for key entropy (McLaren et al., 2019).

The experimental results are unusually strong. For Zbot, Gozi, and TorrentLocker, all three samples were decrypted with 100% success; combined memory analysis and decrypt time was under 1 second; candidate key sets were reduced to 3–6, and IV candidate sets ranged from 79 to 483. Decryption was validated by checking whether plaintext matched HTTP 1.1 and by comparing against OpenSSL server logs. The method thus exposes actual bot commands and ransomware-related communication rather than only classifying traffic as anomalous (McLaren et al., 2019).

A complementary view comes from “Devils in the Clouds: An Evolutionary Study of Telnet Bot Loaders,” which studies Telnet bot loaders rather than payload binaries. In the Mirai model, infection is functionally decoupled: scanning bots discover targets, but a separate loader server performs the actual compromise by logging in over Telnet, testing the environment, selecting a writable path, and fetching or reconstructing the payload. The paper captures request logs in a honeycloud with frontends in China, Singapore, and the United States, tokenizes them by byte type, represents them with BoW, 2-gram, and 3-gram vectors for a total of 8,083 dimensions, and clusters them with agglomerative clustering using Ward linkage and threshold $T$2. From over 3 million items, it reduces the corpus to 4,855 selected logs and then 481 valid items, ultimately identifying eight loader families: Nippon-kami, SEFA, Port, No-path-check, SwitchBlades, Sofia, 6-chars, and whattttttlol (Zhu et al., 2022).

These two works expand InfectBot beyond endpoint detection. They show that infection evidence may reside in volatile cryptographic state or in server-side intrusion command sequences, and that meaningful detection or genealogy can therefore depend on memory artefacts and loader semantics rather than solely on packets or binaries.

5. IoT propagation, federated detection, and active remediation

In IoT settings, InfectBot often refers to early-stage botnet propagation and to the difficulty of intervening on weakly managed devices. “Cross Device Federated Intrusion Detector for Early Stage Botnet Propagation in IoT” uses cross-device federated learning so that each device processes its own packet data locally and returns only model updates to a central coordinator. The threat model emphasizes Initial injection, Secondary injection, and Connection to C&C before later performance and maintenance stages, and the evaluated malware families are Mirai, Bashlite, and Torii. On the MedBIoT dataset, the authors sample 2,000 rows per dataset, obtain 23,793 samples after dropping nulls, and report overall average accuracy 71%, precision 78%, recall 71%, and F1-score 68%. They also study a poisoning scenario in which a malicious client flips labels for packets with source port 23, finding more fluctuation but no catastrophic failure in that experiment (Famera et al., 2023).

The same infection-centric perspective can motivate remediation rather than only detection. “Hey, you, keep away from my device: remotely implanting a virus expeller to defeat Mirai on IoT devices” proposes a collaborative defense in which, at a negotiated time slot, a customer reboots a compromised device and a manufacturer-operated “white” Mirai implants a virus expeller during the brief clean-state window. The expeller removes Mirai’s attack and scan modules, adds a fingerprint-obtaining module and a heart-beating module, kills malicious Mirai processes, closes vulnerable ports, and sends the magic number 0xE84Eb1C8 every minute to the heartbeat service. If heartbeat is lost for 70 seconds, the server rescans and re-implants. The authors cite prior work stating that Mirai can infect a device in about 98 seconds after it is connected to the Internet, which motivates the speed requirement; in their prototype on a Dahua DH-3004 DVR, the average implantation time is about 10 seconds (Cao et al., 2017).

This remediation model is technically distinctive because it treats infection as a race condition around reboot and reinfection. It is also explicitly constrained: it works best when the device is clean, depends on user cooperation in the negotiation phase, may impair functionality by closing ports, and raises legal and ethical concerns about remotely implanting code on customer devices (Cao et al., 2017).

6. InfectBot as propagation of unsafe actions in LLM-controlled robot teams

The most literal recent usage of InfectBot appears in “Propagating Unsafe Actions in LLM Controlled Multi-Robot Collaboration via Single Robot Compromise,” where the term names an attack paradigm for embodied multi-agent systems. The system is modeled as robots $T$3 with controller

$T$4

where $T$5 is an atomic action primitive and $T$6 is an optional coordination message. The attacker has black-box access, interacts with only a single entry robot, and uses natural-language prompts alone. The objective is not merely to jailbreak one robot, but to implant a transferable malicious protocol that spreads through peer communication, producing coordinated unsafe actions across the team (Huang et al., 15 May 2026).

The attack proceeds through trust establishment, relay and policy drift, and full compromise. Algorithm 1 separates a dissemination phase, where adoption is observed and the confirmed set grows, from an activation phase, where unsafe stages are induced on feasible robots. Performance is quantified by three normalized metrics in $T$7: obedience, measuring whether the entry robot accepts and executes malicious inputs; infectiousness, measuring autonomous cascade through the cluster after direct attacker interaction stops; and stealthiness, measuring how small the observable footprint is relative to the total communication footprint. The experimental environment uses NVIDIA Isaac Sim 4.5.0, Isaac Lab 2.1, ROS 2 Humble, and the official Unitree ROS 2 / SDK2 stack, with target models including GPT-3.5-Turbo, Gemini-2.5-Flash, Kimi K2, GPT-4o, and GPT-5.1 (Huang et al., 15 May 2026).

The reported results show rapid and persistent propagation. In the strongest cases, obedience reaches 1.00, infectiousness rises to 0.90, and full compromise requires as few as 3.0 rounds, while maintaining stealthiness 0.81. Unsafe behavior is predominantly propagation-driven rather than purely local: among 832 unsafe events, 38.5% were directly triggered by Robot 0 and 61.5% by forwarded messages; 44.2% occurred at depth at least 3 hops. The paper’s central claim is therefore a safety alignment gap between single-robot and multi-robot settings: local refusal robustness is insufficient when coordination dialogue itself can relay adversarial policy (Huang et al., 15 May 2026).

This usage departs from classical malware, but the infection metaphor remains exact. The compromised agent acts as an infection source, peer communication becomes the transmission channel, and unsafe policy becomes the propagated payload. In that sense, InfectBot generalizes from bot infection to compromise propagation in coordinated autonomous systems.