When Blockchain Becomes a CybersecurityThreat: Understanding Decentralized Command-and-Control

Chapter 1

Introduction

In recent years, botnets have become a source of increasing interest for organized crime, representing an effective method for earning money illegally. Remote Operators sell botnet services to clients eager to perform illicit actions. Among the activities available in the botnet “catalog” are DoS, spam, phishing, and spyware. These activities not only harm individuals and companies but also represent a significant threat to global cybersecurity. Botnets are therefore crucial tools in the landscape of modern cybercrime.

The client-server model was one of the first approaches used in Internet botnets, generally based on Internet Relay Chat (IRC) or websites containing lists of predefined commands. In the case of IRC-based botnets, infected clients connect to an IRC server and access a specific channel to receive commands. The remote operator sends commands to the channel via the IRC server, and the clients retrieve and execute them. However, this type of channel can be easily inhibited by keyword-based filters or by blocking the central server’s IP address.

Over time, the intrinsic vulnerability of the “Single Point of Failure” (SPOF) pushed remote operators toward two main architectural evolutions: the Peer-to-Peer model and Web-based infrastructures with dynamic addressing.

The Decentralized Evolution: Peer-to-Peer (P2P) To completely eliminate the central server, P2P botnets were developed. In this architecture, each infected device (Bot) acts as both client and server, propagating commands and updates to neighboring nodes in a mesh network. The absence of a central server makes the network extremely resilient: shutting down a single node does not compromise the infrastructure. However, this approach entails greater management complexity and difficulties for the remote operator 15 in monitoring the network status.

The Centralized Evolution: HTTP and DGA In parallel, centralized botnets evolved by moving to the HTTP/HTTPS protocol, which allows command traffic to blend in with normal web browsing, bypassing firewalls. To protect C2 Server domains from takedown, the Domain Generation Algorithms (DGA) technique was introduced [6]. Instead of having a static address, the malware uses an algorithm to dynamically generate hundreds or thousands of pseudo-random domains every day. The bot will attempt to connect to these domains until it finds an active one registered by the remote operator. The vastness of the generated domains makes it extremely complex for law enforcement to effectively block the botnet, turning the fight into a continuous chase. Despite the effectiveness of DGAs, this technique remains vulnerable to Sinkholing and predictive analysis by security researchers.

The constant search for a truly uncensorable infrastructure, capable of acting as natural “bulletproof hosting” without SPOF, inevitably led to the adoption of Blockchain technology as a new paradigm for C2 Server channel for botnets. There are multiple reasons why a remote operator would decide to build their botnet based on a blockchain:

• Anonymity: The design of blockchains intends to provide a degree of anonymity (most often pseudonymity) to its users.
• Robustness: The design of (public) blockchains provides censorship-resistance, i.e., it is robust in the sense that it is resistant to blocking.
• Enumeration Resistance: Bots retrieving commands from the blockchain are hidden among all other legitimate users.
• Stealthiness: Due to the growing popularity of blockchains, it is unsuspicious to interact with blockchain networks.
• Simplicity: Due to the large community and open-source tools, taking part in a blockchain P2P network is simpler than setting up a custom P2P protocol.

Due to these intrinsic properties, blockchain appears, in theory, to address the structural weaknesses of the previously described infrastructures.

1.1 Problem Statement

Although these advantages theoretically make blockchain the perfect technology for managing a botnet, its actual fully-on-chain implementation on public blockchains, such 16 as Bitcoin and Ethereum, presents significant economic limitations. As demonstrated by the paper Assessing the Threat of Blockchain-based Botnets [3], the necessity of an upstream channel would make the daily cost unsustainable for the remote operator due to transaction fees. Since public blockchains require a transaction fee (Gas Fee) for every state change, a botnet of thousands of nodes sending periodic “heartbeat” signals or exfiltrated data would drain the remote operator’s wallet in a matter of hours.

Furthermore, storage on Layer-1 (L1) blockchains is extremely expensive and limited, making it unfeasible for hosting complex payloads or large datasets. While a unidirectional channel for sending commands from the C2 server to the bots would theoretically suffice, it is highly impractical for many botnet application scenarios where a remote operator needs to know how many bots are available at any given time or receive command execution outputs. Furthermore, while using a private blockchain would reduce transaction costs, it would entail sacrificing the ideal properties of a public blockchain, such as anonymity, censorship resistance, and robustness against takedowns.

Researchers have also explored other decentralized solutions: the paper Hydras and IPFS: a decentralised playground for malware [2] investigates a full-on-IPFS botnet, utilizing a decentralized environment for file storage. This type of infrastructure solves the cost problem compared to the fully on-chain approach because IPFS has no operational costs. However, this comes at the expense of several relevant functionalities and properties:

• Lack of Consensus Mechanism on Network State: While IPFS and peer-topeer protocols excel at data distribution, they fundamentally lack a mechanism to achieve consensus on the current state of the network. In a decentralized file system, all versions of a file can exist simultaneously. Without a centralized authority or a consensus layer, individual bots cannot deterministically agree on which file represents the active command to be executed “right now”.
• Immutability Management Issues: Since IPFS is a content-addressed storage system, any modification to a command file results in a completely new content identifier (CID). Without a mutable reference point, the remote operator cannot simply “update” a command; they face the challenge of distributing the new hash to the entire fleet without a dedicated communication channel.
• Absence of Native Access Control: IPFS is a permissionless public storage layer where any user can upload content. The system lacks an intrinsic authentication mechanism to restrict who can upload commands. Consequently, protecting the integrity of the command channel on a permissionless layer like IPFS requires 17 additional security measures, such as digital signatures. In a pure P2P/IPFS architecture, the remote operator would need to sign every payload, and every bot would need to embed the public key for verification. While technically feasible, this introduces complexities in Key Management (e.g., key revocation/rotation become difficult without a central authority or a consensus layer) and increases the binary’s footprint.

1.2 Proposed Solution

The proposed solution adopts a hybrid Command and Control architecture that decouples control logic from data distribution and data exfiltration. The control layer is implemented using a Sidechain (specifically Polygon PoS), the data layer relies on the IPFS, and the upstream communication channel for data exfiltration leverages standard HTTP-based protocols.

This architectural separation allows each component to exploit the specific strengths of the underlying technology: blockchain provides a resilient and censorship-resistant coordination mechanism, IPFS offers decentralized and cost-efficient payload distribution, and HTTP/HTTPS enables flexible and replaceable upstream communication.

At the core of the design is a Smart Contract deployed on a public blockchain scaling solution, which functions exclusively as a mutable pointer and consensus anchor. Rather than storing command data directly on-chain, the contract maintains a cryptographic reference to the current command payload hosted on IPFS. By updating this reference, the remote operator can implicitly signal a global state change to the entire botnet without incurring the prohibitive costs associated with fully on-chain implementations. The detailed operational workflow, communication protocols, and security mechanisms of this hybrid architecture are described in Chapter 2.

Figure 1.1: High-level operational workflow of the proposed hybrid architecture.

1.2.1 Key System Properties

The proposed system guarantees the following critical properties:

• Consensus Mechanism: Through the smart contract, the blockchain functions as a mutable pointer, providing the botnet with a deterministic consensus mechanism. This resolves the synchronization issues typical of pure P2P networks.
• State Machine: The blockchain acts as the single source of truth. Bots know the exact state of the network at any instant without needing complex probabilistic algorithms.
• Censorship Resistance: The decentralized nature of both the control layer and the data layermakes the infrastructure robust against domain seizures and server takedowns.
• Cost Viability: By using secondary channels for upstream communication, the only cost for the threat actor is the minimal gas fee to update the pointer on the blockchain. This makes the solution economically sustainable compared to full-on-chain botnets.
• Security & Stealth: Although the Smart Contract is publicly accessible, the system preserves the confidentiality and authenticity of commands through offchain cryptographic protections. Payload confidentiality and analysis resistance are achieved via encryption mechanisms detailed in Section 2.5.3, while command authenticity is natively enforced by the blockchain access control model, which ensures that only the contract owner can update the global state.
• Dynamic Upstream Resolution: To avoid SPOF in the data exfiltration phase, the architecture implements a Dynamic Endpoint Resolution (DER) mechanism. Since the upstream C2 server IP is contained within the encrypted payload on IPFS (and not hardcoded in the malware), the remote operator can easily replace a blacklisted server by simply deploying a new one and updating the pointer on the blockchain.

1.3 Ethical Considerations and Research Safeguards

This research explores the technical feasibility of decentralized C2 architectures for academic and defensive purposes only. The primary objective is to investigate how emerging technologies, such as Layer-2 blockchains and IPFS, can be leveraged to create censorship-resistant infrastructures, thereby providing security researchers and network defenders with the necessary insights to anticipate and mitigate such threats.

1.3.1 Methodological Safeguards

To ensure that this study does not pose any risk to existing systems, several methodological safeguards were strictly implemented during the development and testing phases:

• Isolated Test Environment: All blockchain interactions were conducted on the Polygon Amoy Testnet. No real-value assets were used, and no transactions were performed on mainnet ledgers.
• Simulated Payloads: The modules for DoS and Ransomware included in this Proof of Concept (PoC) are non-functional simulations. They are designed to trigger network signatures and logging events without performing any actual malicious activity on the host system or external targets.
• Controlled Infrastructure: The C2 server and bot agents were deployed on private, isolated cloud instances, ensuring that no external traffic could be affected by the experimental runs.

1.3.2 The Weaponization Gap

It is important to distinguish between the routing logic demonstrated in this PoC and a fully functional cyber weapon. Significant efforts and specialized expertise would be required to bridge the ”weaponization gap” and transform this research into a real-world threat. Specifically, this work intentionally omits:

• Infection and Propagation: The PoC assumes the agent is already present on the target; it lacks any mechanism for initial access, exploitation, or lateral movement.
• Persistence and Evasion: No techniques for system persistence, anti-debugging, or antivirus bypass were implemented.

While the architecture is ”defense-ready” as a tool for signature generation and traffic analysis, its use as an offensive tool would require substantial additional development, reinforcing the academic nature of this implementation.

1.3.3 Code Disclosure and Defensive Utility

The source code for this PoC is intended to be shared with the academic community and security professionals under a responsible disclosure framework. By providing the core logic of the decentralized communication channel, the author aims to foster the creation of behavioral detection rules and network heuristics. The code may be published with certain critical components redacted to prevent immediate abuse by unsophisticated actors, ensuring that its utility remains skewed toward defensive research and infrastructure hardening.

1.4 Contributions of this Thesis

In summary, the main contributions of this work are:

• The formal design of a censorship-resistant hybrid C2 architecture.
• The development of a functional PoC utilizing Polygon PoS and IPFS.
• An experimental evaluation of the proposed solution in terms of cost efficiency, latency, and resilience against takedown attempts.

1.5 Thesis Structure

The remainder of this thesis is organized as follows:

• Chapter 2: System Design and Architecture provides a detailed technical breakdown of the proposed hybrid infrastructure. It defines the Threat Model, analyzes the design requirements, and details the interaction protocols between the Blockchain Control Layer, the IPFS Storage Layer, and the bot entities.
• Chapter 3: Proof of Concept Implementation describes the practical development of the system. It covers the tools and technologies used, the deployment of the Smart Contract on the Polygon testnet, and the implementation of the malware client logic, including the encryption and retrieval mechanisms.
• Chapter 4: Experimental Analysis and Results presents the evaluation of the proposed architecture. It includes a comparative cost analysis against traditional L1 botnets, performance tests regarding command propagation latency, and a discussion on the system’s resilience and stealth capabilities.
• Chapter 5: Conclusions and Future Work summarizes the findings of this research, highlights the current limitations of the implementation, and suggests potential future developments to further enhance the robustness of decentralized botnets.

Chapter 2

System Design

2.1 Requirements

2.1.1 Functional requirements

To operate effectively as a modern, resilient botnet, the proposed hybrid architecture must satisfy the following functional requirements:

• Reliable Command Dissemination: The system must provide a mechanism for the remote operator to broadcast instructions to the entire bot population effectively. The infrastructure must ensure that commands are propagated even if specific network nodes (e.g., IPFS gateways or RPC endpoints) are intermittent.
• State Consistency: The architecture must allow compromised endpoints to deterministically identify the most recent command issued by the remote operator. The system must prevent “replay attacks” or synchronization conflicts where bots might execute obsolete instructions.
• Arbitrary Payload Execution: The C2 infrastructure must be payload-agnostic. It must support the distribution and execution of various types of malicious modules, such as DoS commands, cryptocurrency miners or information stealers, without requiring structural changes to the communication protocol.
• Secure Payload Retrieval: The architecture must support the distribution of command payloads that have been pre-encrypted by the remote operator prior to upload. The system must ensure that while the encrypted data blobs are publicly accessible on the IPFS network, their actual executable content remains confidential and can only be interpreted by bots capable of performing the decryption routine using the correct key.
• Data Exfiltration Channel: The system must define a pathway for bots to report their status (heartbeat) and transmit exfiltrated data back to the remote operator. This channel must be able to survive IP blacklisting.

2.1.2 Non-Functional Requirements

Beyond the core operational capabilities, the hybrid botnet infrastructure must adhere to strict quality constraints to ensure its viability against modern defensive countermeasures. The key non-functional requirements are:

• Censorship Resistance: The infrastructure must eliminate any SPOF in the command distribution chain. The proposed system must leverage the distributed nature of the Blockchain and IPFS to ensure that command data remains available even if individual nodes or gateways are taken offline.
• Economic Feasibility: The operational cost for the remote operator must remain sustainable over time. The system design must overcome the high transaction fees typical of public L1 blockchains. Specifically, the cost of issuing a new command should be negligible, ensuring the botnet remains profitable regardless of the frequency of updates
• Stealth and Evasion: The network traffic generated by the botnet allows it to blend in with legitimate Web3 user activity. Communication relies on standard protocols (HTTP/HTTPS/JSON-RPC) and interacts with reputable, high-reputation domains (e.g., public blockchain RPC endpoints and IPFS gateways) to bypass firewall filtering. While the blockchain ledger is public by definition, payload confidentiality is ensured via off-chain encryption, preventing passive observers from interpreting the command content even if the transaction is detected. Furthermore, to mitigate traffic analysis on the polling frequency, the agent implements randomized jitter in its request intervals.
• Data Integrity and Immutability: The system must guarantee that the command received by a bot is exactly the one issued by the remote operator. The architecture must prevent Man-in-the-Middle (MitM) attacks where a third party could inject fake commands.
• Scalability: The infrastructure must be capable of supporting a growing number of compromised endpoints without performance degradation. The storage layer must handle concurrent download requests from thousands of bots without relying on the remote operator’s bandwidth, effectively functioning as a peer-to-peer Content Delivery Network (CDN).

2.2 Threat Model

To rigorously evaluate the security and resilience of the proposed architecture, this section defines the capabilities of potential adversaries and the assumptions underpinning the system’s design. The adversary is modeled as a composite entity encompassing security researchers, Internet Service Providers (ISPs), and Law Enforcement Agencies (LEAs).

In this thesis, the term remote operator refers to the adversarial actor responsible for issuing commands and managing the botnet, whereas C2 denotes a transient infrastructural component used exclusively for upstream data collection. Unless explicitly stated otherwise, all control decisions and command issuance are attributed to the remote operator

2.2.1 Adversary Capabilities

We assume the adversary possesses the following capabilities aimed at disrupting the botnet or identifying the remote operator:

• Traffic Analysis and DPI: The adversary can monitor network traffic at the ISP level. They can perform Deep Packet Inspection (DPI) to identify non-standard protocols or block connections to known malicious IP addresses. However, they cannot easily distinguish HTTP/HTTPS traffic directed towards legitimate public services (e.g., reputable RPC nodes or IPFS gateways) from malicious C2 traffic.
• Malware Reverse Engineering: The adversary can obtain a sample of the bot binary. Through static and dynamic analysis, they can extract hardcoded artifacts, including the smart contract address and the embedded decryption key. We explicitly acknowledge that security by obscurity is not permanent: once the binary is analyzed, the adversary can decrypt and inspect the payloads stored on IPFS. However, this capability does not allow the adversary to inject arbitrary commands or hijack the botnet, as command authenticity and state updates remain cryptographically enforced by the blockchain access control mechanism.
• Takedown Operations: The adversary has the legal authority to seize domain names, shut down centralized servers (VPS), and pressure service providers to blacklist specific IPs. They can also request the removal of content from managed IPFS gateways, although they cannot purge data from the underlying decentralized DHT.
• Blockchain Analysis: The adversary can observe all transactions on the public ledger. They can track the remote operator’s wallet address, monitor state updates in real-time, and attempt to trace the source of funds used for gas fees (Deanonymization attacks).

These attack vectors are visually mapped onto the proposed architecture in Figure 2.1.

Figure 2.1: Threat model diagram mapping adversary capabilities to specific architectural components.

2.2.2 Security Assumptions

The design of the hybrid infrastructure relies on the following security assumptions:

• Computational Hardness: We assume that standard cryptographic primitives (e.g., AES-256 for payload encryption, ECDSA for blockchain signatures) are secure against brute-force attacks within a reasonable timeframe.
• Blockchain Liveness and Censorship Resistance: We assume that the underlying high-performance sidechain remains operational and that its consensus mechanism prevents the censorship of valid transactions. While individual RPC endpoints may blacklist the botnet’s requests, the blockchain network itself acts as an immutable “bulletproof” medium.
• Remote operator Operational Security (OpSec): We assume the remote operator utilizes anonymization techniques, such as crypto mixers, privacy coins, or stolen funds to fund the wallet interacting with the smart contract, preventing financial traceback.
• Ephemeral Upstream Channels: We assume that any centralized server used for data exfiltration will eventually be detected and blocked. The system security does not rely on this server remaining hidden indefinitely, but rather on the agility to replace it via the blockchain-based pointer mechanism.

2.3 Blockchain Fundamentals

Before detailing the proposed hybrid architecture, it is essential to define the intrinsic characteristics of blockchain technology that make it a uniquely resilient infrastructure. While Chapter 1 outlined the advantages from an threat actor’s perspective, this section analyzes the technical origins of these properties, specifically decentralization, security, censorship resistance, and unstoppability.

2.3.1 Decentralization

Decentralization is not merely a feature but the structural foundation of blockchain systems. Unlike traditional client-server architectures where the network state is maintained by a central authority (creating a SPOF), a blockchain is maintained by a distributed network of peer-to-peer nodes. Each full node stores a copy of the ledger and participates in validation. This architecture ensures that the system survives even if a significant portion of the network is compromised or taken offline.

2.3.2 Security and Immutability

The security of the ledger derives from the combination of cryptographic hashing and consensus mechanisms.

• Cryptographic Linking: Transactions are grouped into blocks, and each block contains the cryptographic hash of the previous one. Within each block, transactions are organized in a Merkle Tree structure [4], which allows for efficient and secure verification of content integrity. This creates a chain where modifying a past transaction would require recomputing all subsequent blocks, which is computationally infeasible.
• Consensus Protocol: State changes are not authorized by an administrator but by a consensus protocol (e.g., Proof of Stake in Polygon). This ensures that valid updates are processed deterministically based on cryptographic signatures, regardless of the malicious intent behind the transaction.

2.3.3 Censorship Resistance

Censorship resistance refers to the neutrality of the protocol: the network processes valid transactions regardless of the sender’s identity or the payload’s content. In a sufficiently decentralized public blockchain, there is no central gatekeeper with the authority to blacklist a specific wallet or block a transaction. To censor the botnet’s command update, an adversary would need to overwhelm the entire network’s consensus (e.g., a 51% attack [5]), a scenario economically impractical for major chains.

2.3.4 Unstoppability

Closely related to censorship resistance, unstoppability refers to the continuous availability of the infrastructure. Public blockchains operate on thousands of globally distributed nodes across different jurisdictions. Consequently, there is no ”off switch” or single legal entity that law enforcement can pressure to shut down the network. For a botnet, this guarantees a C2 channel that is permanently available, rendering traditional takedown operations (such as domain seizure or server physical seizure) ineffective.

2.4 The Control Layer: Blockchain as a State Machine

The core of the proposed botnet architecture is the control layer, implemented as a smart contract deployed on the Polygon PoS sidechain. In this hybrid design, the blockchain is not used to store the command payloads directly but rather to serve as a highly resilient, immutable signaling channel. This component acts as the “brain” of the infrastructure, maintaining the authoritative state of the network.

2.4.1 Smart Contract Logic: The Mutable Pointer

Unlike traditional botnets that rely on complex server-side logic to distribute commands, the on-chain component of this architecture is deliberately minimized to ensure cost efficiency and stealth. Conceptually, the smart contract functions as a Mutable Pointer. 28 The logic represents a minimal State Machine that maintains a single critical state variable: the currentCID.

• The Registry: This string variable stores the CID of the most recent configuration or command payload hosted on the IPFS network.
• The Update Mechanism: The contract exposes a setter function that allows the state to be overwritten. When the remote operator wants to issue a new command, they simply send a transaction that updates the currentCID variable with the new hash.
• The Retrieval Interface: The contract exposes a public “getter” function. Infected bots utilize standard RPC calls to read this variable. Crucially, reading data from the blockchain state is a read-only operation that does not require a transaction and incurs zero gas fees for the bots.

This design effectively transforms the immutable blockchain into a dynamic broadcasting channel. By simply changing the pointer, the remote operator can redirect the entire bot fleet to a new set of instructions, achieving near-instant propagation once the transaction is included in a block.

2.4.2 Access Control Mechanism

A critical security requirement for any C2 channel is preventing unauthorized takeovers. In a centralized model, authentication is typically handled by server-side login credentials, which can be stolen or bruteforced. In this decentralized architecture, authentication is cryptographic and native to the blockchain.

The smart contract implements a strict access control mechanism. This logic restricts the execution of the state-update function exclusively to the wallet address that deployed the contract (the remote operator). The security guarantee consists of two aspects:

• Authenticity: The blockchain consensus protocol verifies the digital signature of every transaction. A valid update to the currentCID can only be generated by someone possessing the remote operator’s private key.
• Integrity: Infected bots do not need to implement complex signature verification schemes internally. They simply trust the state of the smart contract. Since the blockchain acts as a tamper-proof ledger, if the currentCID changes, the bots can be mathematically certain that the command originated from the owner of the contract.

2.4.3 Choice of Ledger: Polygon PoS Sidechain

While the proposed architecture is theoretically compatible with any EVM-based blockchain (such as Ethereum Mainnet), this thesis selects Polygon PoS as the optimal deployment environment. This decision is directly driven by the non-functional requirements defined in Section 2.1, specifically economic feasibility and scalability.

Although technically classified as a Sidechain of Ethereum rather than a strict Layer-2 (L2) rollup, as it relies on its own Proof-of-Stake consensus mechanism for security, Polygon acts as an effective scaling solution. Unlike independent blockchains, Polygon maintains a symbiotic relationship with the Ethereum Mainnet by periodically checkpointing its state root to the main chain. This mechanism provides a degree of security inheritance while offering the following advantages:

• High Throughput and Fast Finality: Polygon’s consensus allows for rapid block times (∼2 seconds) with probabilistic finality. This ensures that command updates are confirmed and propagated to bots almost immediately, minimizing latency compared to Ethereum’s 12-second block time.
• Negligible Operational Costs: Transaction fees on the Polygon sidechain are typically fractions of a cent ($0.001 - $0.01). This satisfies the economic feasibility requirement, allowing the remote operator to issue frequent updates without draining financial resources.
• EVM Compatibility: Being fully compatible with the EVM allows the use of standard development tools and RPC interfaces. The bot can interact with the Polygon sidechain exactly as it would with Ethereum, making the development process indistinguishable from legitimate DApp creation.

2.5 The Data Layer: IPFS and Payload Management

While the blockchain serves as the immutable command channel, it is fundamentally ill-suited for storing substantial amounts of data due to block size limits and prohibitive storage costs. To overcome this, the architecture employs the IPFS as the decentralized storage layer. This component effectively functions as a peer-to-peer CDN, hosting the actual instructions and binaries that the botnet must execute

2.5.1 Content Addressing and the Need for a Pointer

The fundamental architectural shift adopted in this proposal is the transition from location addressing to content addressing. In traditional web protocols (HTTP/HTTPS), resources are retrieved based on their location (e.g., 192.168.1.5/config.json). If the server at that specific IP address is seized or taken offline, the link breaks, and the resource becomes unavailable.

IPFS, conversely, retrieves data based on a cryptographic hash of its content. This mechanism introduces a unique property: immutability. If the remote operator modifies even a single bit of the command file (e.g., changing the target IP for a DDoS attack), the resulting CID will be completely different. Consequently, an IPFS link cannot be “updated” in the traditional sense; it can only be replaced.

This creates a synchronization challenge: how do bots know which CID represents the current command? This is precisely why the Blockchain Control Layer (Section 2.4) is indispensable. The smart contract acts as the mutable pointer that links the static, immutable snapshots stored on IPFS with the dynamic operational needs of the remote operator. The bots query the blockchain to find the “pointer,” and then query IPFS to retrieve the payload.

2.5.2 Payload Structure

The file stored on IPFS is not merely a raw executable but a structured configuration object. Once decrypted, the payload follows a strict JavaScript Object Notation (JSON) schema designed to provide the bot with all necessary operational parameters. The logical structure of a standard command payload includes:

• command id (Integer): A unique, monotonically increasing sequence number (nonce). This is crucial for state consistency, allowing the bot to distinguish between a new command and an old one, preventing “replay attacks” or redundant executions.
• execution time (Timestamp): A Unix timestamp indicating when the command should be executed. This allows for synchronized attacks (e.g., a time-coordinated DDoS) even if bots retrieve the payload at slightly different times.
• task type (String): Defines the module to be activated (e.g., "DDOS FLOOD", "MINER START", "INFO STEALER").
• target params (Object): Contains specific arguments for the task, such as the target IP address, port number, or wallet address for mining.
• upstream server ip (String): This is the implementation of the dynamic upstream resolution mechanism. It specifies the current IP address or domain of the C2 server where the bot must exfiltrate data (logs, stolen credentials, or heartbeats). By including this field in the payload rather than hardcoding it in the binary, the remote operator can rotate collection servers instantly to evade blacklisting.

2.5.3 Confidentiality Strategy

A primary challenge of using public decentralized storage is that data on IPFS is globally accessible; any observer with the CID can download the file. To comply with the Stealth and evasion requirements defined in Section 2.1, the system implements a strict off-chain encryption policy. The file uploaded to IPFS is never the cleartext JSON described above, but an encrypted blob. The confidentiality strategy relies on symmetric cryptography:

• Encryption: Before the upload phase, the remote operator encrypts the JSON payload using AES-256.
• Obfuscation: The resulting output appears to the IPFS network as high-entropy random noise, indistinguishable from other encrypted data or compressed archives.
• Key Management: The decryption key is not stored on the blockchain nor on IPFS. Instead, it is distributed “off-chain”, specifically, it is hardcoded or obfuscated within the initial bot malware binary distributed to compromised endpoints.

This ensures that while the metadata (transaction logs on the blockchain, file existence on IPFS) is public, the operational intelligence (who is the target, where is the C2 server) remains confidential. Even if a security researcher identifies the malicious CID on the blockchain, they cannot interpret the payload without first reverse-engineering the bot to extract the key.

2.6 Communication Protocols

The resilience of the proposed architecture relies fundamentally on the strict decoupling of command dissemination (Downstream) and data reporting (Upstream). Unlike traditional centralized botnets that often utilize persistent bidirectional TCP connections, which are easily detectable via traffic analysis, this system utilizes distinct, asymmetric protocols for each direction to maximize stealth and survivability.

2.6.1 Downstream Channel: Command Propagation

The downstream channel represents the flow of information from the remote operator to the infected agents. To eliminate the single point of failure associated with central command servers, this channel operates entirely through public, decentralized infrastructure.

The Polling Mechanism Compromised endpoints do not maintain a persistent network connection with the control infrastructure. Instead, they implement a “pull-based” Polling Mechanism. At randomized intervals (defined by a jitter parameter T ± ∆t to avoid network spikes), the bot initiates a standard HTTP/HTTPS JSON-RPC request to a public blockchain node. The request queries the currentCID variable of the smart contract This approach offers two advantages:

• Stealth: The traffic appears as legitimate interaction with public blockchain APIs, making it difficult for firewalls to distinguish from normal user activity.
• Asynchronicity: Bots can go offline and come back online without disrupting the network topology; upon reconnection, they simply fetch the latest state from the blockchain.

RPC Rotation Strategy A known vulnerability of blockchain-based malware is reliance on specific RPC providers (e.g., Infura, Alchemy, Ankr). If a security provider identifies the botnet’s traffic pattern, it can blacklist the originating IPs or the target contract address, effectively disrupting command retrieval.

To mitigate this risk, the bot agent implements a robust RPC rotation strategy. The binary contains a diversified list of public RPC endpoints. The communication logic operates on a failover basis: if a connection attempt results in an error (e.g., HTTP/HTTPS 403 Forbidden), the bot automatically rotates to the next provider in the list.

Limitations and Trustless Verification While the RPC rotation strategy significantly raises the operational barrier for defenders, it relies on two assumptions:

1. Finite Set Availability: The list of endpoints is finite. A large-scale coordinated block could theoretically censor all hardcoded providers.
2. RPC Trust: Standard JSON-RPC calls assume the provider is honest. An adversary controlling a node (e.g., via legal pressure) could return falsified state data to prevent the bot from updating.

To address these advanced threat vectors, the architecture can be extended to incorporate Light Client mechanics (such as Helios[1]). Unlike standard RPC clients, a LightClient does not blindly trust the response. Instead, it syncs with the blockchain block headers and requests a Merkle Proof alongside the state variable. By cryptographically verifying that the retrieved currentCID is contained within the state root of a valid block header signed by the validator set, the bot achieves trustless command retrieval. This renders the infrastructure immune to falsified responses from compromised RPC providers and allows the bot to participate in P2P discovery to find new nodes dynamically, overcoming the limitations of static lists.

2.6.2 Upstream Channel: Data Exfiltration

The upstream channel handles the transmission of sensitive data from the bots back to the remote operator. Since this involves sending large volumes of data to a specific destination, it is the component most susceptible to tracking and takedown.

Dynamic Endpoint Resolution To address this vulnerability, the architecture introduces a dynamic endpoint resolution mechanism. In traditional malware, the C2 server IP address or domain is often hardcoded within the binary or generated via a predictable DGA. If analysts extract this address, they can block it permanently. In this proposed solution, the destination address for data exfiltration is not present in the malware binary. Instead, the C2 server IP is encapsulated within the encrypted payload hosted on IPFS. This creates a flexible and resilient exfiltration path:

• Disposability: The remote operator treats collection servers as disposable assets.
• Agility: If the current collection server is identified and shut down by authorities, the remote operator simply deploys a new server.
• Recovery: To restore the flow of data, the remote operator uploads a new JSON configuration containing the new IP address to IPFS and updates the pointer on the smart contract.
• Redirection: During the next polling cycle, all bots verify the state change, download the new configuration, and immediately redirect their exfiltration traffic to the new server

This mechanism renders static IP blacklisting ineffective, as the “target” can be moved infinitely without ever requiring the bot software to be recompiled or redistributed.

2.7 Operational Workflow

This section details the end-to-end operational lifecycle of the botnet. The interaction between the components follows a strict sequence of cryptographic verifications and state updates. The comprehensive workflow is illustrated in the UML Sequence Diagram in Figure 2.2.

2.7.1 Bootstrapping

The bootstrapping phase refers to the initial initialization logic executed immediately after the bot infects a new host. Unlike the cyclical command update, this process occurs only once per infection.

1. Persistence Establishment: Upon execution, the malware installs itself into the host system to ensure survival across reboots.
2. Key Initialization: The bot loads the hardcoded decryption key and the smart contract address into memory.
3. Initial Synchronization: The bot does not have a “current state.” It immediately triggers the Polling (described in Phase 2 of Figure 2.2) to fetch the latest CID from the blockchain. This ensures that even a bot infected months after the campaign started will immediately sync with the most recent command issued by the remote operator.

As detailed in Figure 2.2, the core operational loop is divided into three distinct phases:

2.7.2 Phase 1: Payload Publication (Steps 1-7)

The process is initiated by the remote operator. To ensure confidentiality, the payload is encrypted locally (Step 1) before being uploaded to the IPFS network (Step 2). IPFS returns a unique CID (Step 3). Subsequently, the remote operator sends a transaction to a Blockchain RPC Node (Step 4), calling the setCID function. The transaction propagates through the network, the smart contract state is updated (Step 5), and the change becomes immutable on the ledger.

2.7.3 Phase 2: Command Retrieval & Polling (Steps 8-13)

Infected bots operate on a polling loop (every T seconds). The bot initiates an RPC Call to query the smart contract (Step 8). The Node returns the current CID (Step 10). A critical optimization prevents redundant traffic: the bot compares the retrieved CID with the one stored in its local memory.

• If CID new == CID old: The bot remains idle.
• If CID new != CID old: The bot recognizes a new command (Step 12), requests the file from IPFS via the new CID, and downloads the encrypted blob (Step 13).

2.7.4 Phase 3: Execution & Reporting (Steps 14-16)

Upon download, the bot uses the embedded key to decrypt the payload (Step 14) and executes the instructions (Step 15). Finally, the output is exfiltrated via a standard HTTP/HTTPS request to the C2 server IP defined in the payload (Step 16).

2.7.5 Resilience and Recovery Protocols

The architecture includes specific protocols to handle infrastructure failures, ensuring the botnet cannot be easily dismantled.

IPFS Data Persistence (Pinning) A common issue with IPFS is garbage collection: if a file is not requested frequently, nodes may delete it to save space. To prevent the payload from disappearing, the remote operator utilizes pinning services (e.g., Pinata, Infura IPFS, or a dedicated node). This guarantees that the encrypted payload remains available on the network indefinitely, ensuring that new bots can always retrieve the command referenced by the blockchain.

Upstream Failure Recovery If the upstream C2 server is taken down by law enforcement:

1. Bots attempting to upload data will receive connection errors (timeout/connection refused).
2. The bots are programmed to fail silently and return to the Polling State (Phase 2).
3. They continue to query the Blockchain.
4. Once the remote operator deploys a new C2 server and updates the payload on IPFS (and the pointer on-chain), the bots will download the new configuration containing the fresh IP address.
5. Data exfiltration resumes automatically towards the new destination.

Figure 2.2: Detailed operational workflow of the hybrid C2 architecture.

Chapter 3

Proof of Concept Implementation

This chapter details the practical implementation of the PoC designed to validate the theoretical architecture presented in Chapter 2. The primary objective of this PoC is to demonstrate both the technical feasibility and the economic sustainability of a decentralized command and control infrastructure using real-world, actively deployed technologies.

3.1 Overview of the Hybrid Architecture

The implemented system is built upon a tripartite hybrid topology. This architecture is carefully engineered to decouple the immutable control logic from the dynamic, highbandwidth requirements of data exfiltration. This strict separation of concerns is realized through three distinct operational layers:

• The Control Layer: Serving as the unalterable core of the botnet, a smart contract deployed on the Polygon Amoy testnet acts as the resilient, censorshipresistant anchor. Instead of storing complex instructions, it holds a single, mutable cryptographic pointer. This provides a deterministic consensus mechanism for the entire infected population without incurring the prohibitive gas fees associated with fully on-chain botnets.
• The Storage Layer: The IPFS functions as a decentralized, peer-to-peer CDN. It is utilized exclusively to host the encrypted command payloads. This layer guarantees high availability, censorship resistance for the payload files, and effectively zero-cost bandwidth for the threat actor, regardless of the botnet’s scale.
• The Data Exfiltration Layer: Standard collection servers based on the HTTP/HTTPS protocol are deployed to handle the upstream traffic. Unlike traditional C2 architectures that both issue commands and receive data, these endpoints act solely as passive listeners for bot telemetry and the outputs of executed malicious tasks.

3.2 The Signaling Layer: Smart Contract on Polygon

The foundational component of the control infrastructure is a Smart Contract deployed on the Polygon Amoy test network. This component acts as the definitive “source of truth” for the entire botnet, implementing the m utable pointer logic described in the architectural design

3.2.1 Deployment Environment: Polygon Amoy

The PoC utilizes the Polygon Amoy testnet rather than the Polygon Mainnet. Amoy is the official test network for Polygon PoS, providing a fully functional EVM-compatible environment where transactions are paid using testnet gas (POL tokens obtained from public faucets).

This choice is optimal for the PoC because it perfectly mirrors the network topology, block times, and RPC interaction mechanics of the production Mainnet, allowing for accurate latency and reliability testing without incurring actual financial costs during the development and evaluation phases.

3.2.2 Contract Implementation

The smart contract, named BotnetC2.sol, is deliberately minimalist. By minimizing the on-chain logic, the remote operator reduces the computational complexity of the contract, thereby keeping the gas fees required for state updates as low as possible.

The complete Solidity implementation used in this PoC is presented below:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract BotnetC2 {
    address public owner;
    string public currentCID;

    // The constructor sets the deployer as the owner
    constructor() {
        owner = msg.sender;
    }

    // Function to update the pointer to the latest IPFS payload
    function setCID(string memory _newCID) public {
        require(msg.sender == owner, "Unauthorized: Access Denied");
        currentCID = _newCID;
    }
}

3.2.3 Access Control and Gasless Retrieval

Despite its simplicity, the contract rigidly enforces the security requirements of the C2 channel through two native blockchain mechanisms:

• Cryptographic Authentication: The setCID function includes a require statement that acts as the access control layer. It verifies that the msg.sender (the wallet address signing the transaction) matches the owner variable set during deployment. This guarantees that only the remote operator holding the correct private key can alter the CID. Any attempt by an unauthorized actor (e.g., a security researcher or a hijacked node) to overwrite the pointer will be deterministically rejected by the network consensus.
• Gasless Polling: The currentCID variable is declared as public, meaning the Solidity compiler automatically generates a “getter” function for it. When the bot performs its periodic Polling, it executes a eth call RPC request rather than an eth sendRawTransaction. Because reading the state of the Blockchain does not modify the ledger, it requires zero gas. This asymmetry allows a massive fleet of bots to continuously monitor the channel without placing any financial burden on the threat actor.

3.3 The Storage Layer: IPFS and Payload Management

While the Blockchain provides an unstoppable signaling channel, its block size limitations and gas costs make it entirely unsuitable for hosting execution logic or large configuration files. To resolve this bottleneck, the architecture relies on the IPFS to host the actual command Payloads.

This section details how the remote operator constructs, secures, and distributes these payloads across the decentralized network.

3.3.1 Payload Structure and Dynamic Configuration

The operational intelligence of the botnet is encapsulated within a structured JSON object. Instead of hardcoding static instructions into the malware binary, the remote operator generates a dynamic configuration file for every new campaign.

A representative payload generated by the PoC takes the following structure:

{
  "command_id": 1774435204,
  "timestamp": "2026-03-25T10:40:04Z",
  "upstream_server": "http://35.172.118.8:5000",
  "version": "2.0",
  "type": "DDOS_SIMULATION",
  "target_ip": "8.8.8.8",
  "params": {
    "duration": 10,
    "method": "HTTP_FLOOD",
    "threads": 4
  }
}

This structure satisfies several architectural requirements:

• Idempotency and State Tracking: The command id is generated using the Unix timestamp of creation. When a bot downloads the payload, it compares this ID against its locally stored execution history. This mechanism prevents replay attacks and ensures that a bot does not execute the same command multiple times if the polling cycle repeats before a new update is issued.
• Dynamic Upstream Resolution: The upstream server field embodies the server flux concept. By injecting the current C2 server IP directly into the payload, the remote operator achieves total infrastructure agility, completely decoupling the immutable command layer from the disposable exfiltration layer.

3.3.2 Cryptographic Confidentiality

To ensure stealth and data confidentiality, the PoC implements an aggressive off-chain encryption strategy. Before interacting with the IPFS network, the remote operator CLI encrypts the serialized JSON bytes using AES-256 in CBC mode (implemented via the Python cryptography.fernet library).

The resulting output is a high-entropy binary blob. The symmetric decryption key is never exposed on the Blockchain or IPFS; it is pre-shared and obfuscated within the initial malware agent distributed to the compromised endpoints. Consequently, while the Blockchain ledger transparently broadcasts the state change, the actual operational intelligence remains mathematically inaccessible to third-party observers lacking the appropriate cryptographic material.

3.3.3 IPFS Pinning and Operational Security

To guarantee that the encrypted payload remains perpetually available for both active bots and newly compromised endpoints, the PoC utilizes Pinata, an IPFS pinning service. Pinning prevents the decentralized network’s garbage collection mechanisms from purging the file.

Furthermore, the implementation demonstrates operational security (OpSec) awareness regarding file management. When interacting with the Pinata API, the remote operator interface dynamically names the uploaded binary blobs based on their internal metadata (e.g., cmd DDOS SIMULATION 1774435204.bin). While this filename is visible on the threat actor’s private pinning dashboard—facilitating campaign tracking and management—the IPFS network only identifies the file via its cryptographic CID. This ensures that the public-facing storage layer reveals no contextual metadata about the payload’s nature to passive observers.

3.4 The threat actor’s Interface: remote operator CLI

To orchestrate the complex interactions between the local environment, the decentralized storage, and the blockchain ledger, the PoC includes a dedicated command line

Figure 3.1: threat actor-side view of the IPFS pinning service (Pinata) files dashboard showing encrypted command payloads with dynamic, management-oriented filenames.

interface (CLI) application. Developed in Python, the remote operator CLI acts as the centralized control panel from which the remote operator defines campaign parameters and dispatches commands to the bot fleet.

The CLI automates a four-step execution pipeline to ensure that command issuance is rapid, secure, and resilient against operator errors.

3.4.1 Payload Generation

The first phase involves the PayloadFactory class, which dynamically constructs the JSON Payload based on the threat actor’s input. The CLI provides an interactive menu allowing the operator to select the desired attack module (e.g., DoS Simulation, Connectivity Check, Kill Switch). During this phase, the operator also specifies the dynamic C2 upstream server, which is injected into the payload to ensure the server flux capability described in Section 3.1.

3.4.2 Local Encryption

Once the JSON object is structured, it must be secured before leaving the threat actor’s machine. The CLI utilizes the cryptography.fernet module to perform symmetric encryption. The script reads a locally stored secret.key (which must be identical to the one embedded in the bot binaries) and encrypts the serialized JSON bytes. This ensures that data is protected at rest and in transit, fulfilling the stealth requirement.

3.4.3 IPFS Pinning via API

The encrypted binary blob is then pushed to the IPFS network. Rather than running a local IPFS node, which could expose the threat actor’s origin IP address, the CLI interacts with the Pinata REST API via standard HTTP/HTTPS POST requests. The script transmits the encrypted file along with the dynamic metadata (the campaignspecific filename). Upon a successful upload, the Pinata gateway returns a JSON response containing the immutable CID of the newly hosted file.

3.4.4 Blockchain State Update (Web3 Transaction)

The final and most critical phase is updating the Smart Contract to point to the new CID. To achieve this, the CLI leverages the Web3.py library to interface with the Polygon Amoy testnet. The operational flow of the transaction is fully automated:

1. Connection: The script connects to a public Polygon RPC endpoint.
2. Transaction Building: It constructs a transaction object invoking the setCID(string) function of the deployed contract, passing the newly acquired CID as the argument. The script automatically estimates the required gas limit and fetches the current gas price.
3. Off-chain Signing: The transaction is cryptographically signed locally using the remote operator’s private key, which is loaded from secure environment variables (.env). This ensures the private key is never transmitted over the network.
4. Broadcasting and Finality: The signed raw transaction is broadcasted to the network. The CLI then enters a blocking wait state (wait for transaction receipt), pausing execution until the network validators mine the transaction into a block, thereby confirming the global state change.

By encapsulating these complex Web3 and IPFS interactions into a streamlined CLI, the architecture proves that operating a highly decentralized, censorship-resistant botnet requires no more operational overhead for the threat actor than managing a traditional centralized C2 server.

Figure 3.2: Transaction history of the BotnetC2 smart contract on the Polygon Amoy block explorer, demonstrating repeated, low-cost invocations of the setCID state-update function by the remote operator.

3.5 The Malware Agent: Execution Logic

The bot represents the active component of the architecture, executing on the compromised host. Its primary directive is to autonomously maintain synchronization with the remote operator’s commands while remaining undetected by local security mechanisms. The execution logic is entirely decoupled from the command generation phase, operating in a continuous, asynchronous loop.

3.5.1 Stealth and the Minimal ABI

To interact with the Smart Contract on the Polygon Sidechain, the bot requires the contract’s application binary interface (ABI). In standard decentralized application (DApp) development, the full ABI is imported as a large JSON file. However, distributing a malware agent with external dependencies or large, predictable JSON artifacts compromises its stealth and increases its forensic footprint.

To mitigate this, the PoC agent implements a minimal ABI strategy. The bot only hardcodes the specific interface required to read the state variable, discarding all other contract metadata and write-access functions.

MINIMAL_ABI = [
{
" inputs ": [] ,
" name ": " currentCID " ,
" outputs ": [{" internalType ": " string " , " name ": "" , " type ": "
string "}] ,
" stateMutability ": " view " ,
" type ": " function "
}
]

By embedding this minimal array directly into the Python script (or the compiled binary executable), the bot eliminates the need for local file reads and significantly reduces its static signature, making heuristic detection more difficult.

3.5.2 Polling and State Synchronization

The bot’s core operational loop relies on a periodic Polling mechanism. At defined intervals, the agent initiates an eth call to a public RPC endpoint, querying the currentCID function using the Minimal ABI. As discussed in Section 3.2, this is a read-only operation requiring no gas or wallet authentication.

Upon receiving the CID from the Blockchain, the bot performs a state comparison against its last known command ID. If the retrieved CID matches the local state, the bot returns to sleep, minimizing unnecessary network traffic. If the CID differs, the bot recognizes a state change and transitions to the retrieval phase.

3.5.3 Payload Retrieval and In-Memory Decryption

Once a new command is detected, the bot constructs an HTTP/HTTPS GET request to an IPFS gateway using the retrieved CID. The downloaded file is the AES-256 encrypted binary blob.

To prevent leaving forensic evidence on the compromised endpoint’s disk, the decryption process occurs entirely in memory. The bot applies the pre-shared symmetric key to decrypt the blob, loads the resulting JSON string, and parses the operational parameters: Task Type, Target IP, Duration, and Upstream C2.

3.5.4 Execution Modules (Simulated Capabilities)

Depending on the type field parsed from the Payload, the agent routes the parameters to specific execution modules. For the purpose of this academic PoC, these modules simulate malicious behavior without causing permanent harm to the host or external networks:

• DoS Simulation: The bot spawns multiple concurrent threads to simulate volumetric attacks (HTTP Flood or TCP SYN) against the specified target ip for a defined duration.
• Ransomware Simulation: The module traverses a predefined dummy directory on the local filesystem. It encrypts the target files appending a specific extension (e.g., .enc) and drops a simulated ransom note text file, proving the capability to execute localized sabotage.
• Mining Simulation: To simulate cryptojacking, the bot executes a mathematical workload designed to saturate the CPU for a specified duration, emulating the behavior of a Monero miner.
• Kill Switch: If the remote operator issues an emergency stop, this module halts all active threads, flushes the local state, and securely terminates the bot process, simulating an evasion tactic to avoid forensic capture.

Upon completion of any module, the bot aggregates the execution metrics (e.g., packets sent, files encrypted) and forwards the report to the dynamic upstream C2 server, completing the operational cycle.

3.6 The Ephemeral Exfiltration Server

The final component of the PoC architecture is the upstream data collection infrastructure. In a traditional botnet, the C2 server acts as the central hub for both dispatching commands and receiving stolen data, creating a critical SPOF. In this hybrid model, the collection server is deliberately stripped of all command-issuing capabilities. It functions strictly as an ephemeral, passive listener.

3.6.1 Implementation and Endpoints

To demonstrate this capability, a lightweight HTTP/HTTPS web server was implemented using the Python Flask framework and deployed on an Amazon Web Services (AWS) EC2 instance. The server is designed to be highly portable and stateless regarding the botnet’s command logic. It relies on a simple local SQLite database to store incoming telemetry, avoiding complex infrastructure setups that would slow down rapid deployment.

The listener exposes two primary representational state transfer (REST) API endpoints to handle the upstream traffic generated by the bot fleet:

• /heartbeat (POST): This endpoint receives periodic ”check-in” signals from compromised endpoints. The payload typically includes a unique Bot ID (generated based on hardware identifiers) and a timestamp. This allows the remote operator to monitor the active size of the botnet and identify offline nodes without querying the Blockchain.
• /exfiltrate (POST): This endpoint is utilized by the execution modules to upload the results of their malicious activities. Depending on the task, the bot transmits JSON-formatted reports containing metrics such as successful DoS packet counts, simulated ransomware encryption logs, or computational proofs from the mining module.

3.6.2 Monitoring Interface: The C2 Dashboard

To provide the remote operator with real-time visibility over the infected population, the Flask application includes a web-based graphical user interface (GUI). This dashboard dynamically queries the local SQLite database to display the telemetry data collected via the /heartbeat endpoint.

As shown in Figure 3.3, the interface tracks essential metrics for each bot, including its unique cryptographic ID, the source IP address, and the timestamp of the last received signal. The server calculates the ”Online/Offline” status by comparing the current time with the last heartbeat timestamp, allowing the threat actor to easily monitor the active size and health of the botnet without needing to directly interact with the Blockchain or IPFS layers.

Figure 3.3: The web-based C2 Dashboard displaying a registered bot, its telemetry data, and current online status based on SQLite persistence.

3.6.3 Disposable Infrastructure and Takedown Resistance

The architectural significance of this listener lies in its disposability. Because the server only receives data and its IP address is dynamically resolved by the bots via the encrypted IPFS payload, the remote operator does not need to protect this infrastructure from discovery or takedowns.

If a cybersecurity firm or a hosting provider (such as AWS) detects the malicious incoming traffic and terminates the instance, the impact on the botnet is negligible. The bots simply experience an HTTP/HTTPS timeout when attempting to exfiltrate data. They are programmed to catch this exception, suppress the error, and return to their polling cycle.

To restore the data flow, the remote operator merely spins up a new Flask instance on a different VPS provider, updates the upstream server field in the local CLI, generates a new IPFS Payload, and points the smart contract to the new CID. The entire botnet seamlessly pivots its upstream traffic to the new ephemeral listener, effectively rendering IP blacklisting and server seizures futile.

Chapter 4

Experimental Analysis and Results

The preceding chapters established the theoretical foundation and the technical implementation of the hybrid C2 architecture. This chapter presents the experimental evaluation of the developed PoC. The primary objective of this analysis is to empirically validate the system’s operational viability, focusing specifically on command propagation latency, economic sustainability, and overall infrastructure resilience when deployed in a real-world, geographically distributed network environment.

4.1 Experimental Setup

To accurately assess the performance characteristics of the botnet, the evaluation could not be limited to a simulated, localhost environment. Such a localized test would artificially eliminate network latency, routing delays, and consensus finality times, yielding unrealistic results.

Therefore, a geographically distributed testbed was provisioned to accurately emulate the operational conditions of a live cyberattack campaign.

4.1.1 Infrastructure Components and Geographical Distribution

The experimental environment was divided into three distinct logical and physical domains:

• The threat actor Domain (remote operator): The command generation, payload encryption, and blockchain transaction signing were executed on a local machine situated in Milan, Italy. This machine operated on a standard residential broadband connection, simulating a typical threat actor’s operational base without the benefit of enterprise-grade cloud bandwidth.
• The Decentralized Domain (Control and Storage):

– Control Layer: The Smart Contract was deployed on the Polygon Amoy

Testnet, a globally distributed Sidechain. State updates were

broadcasted via public JSON-RPC endpoints.

– Storage Layer: The encrypted Payloads were uploaded to the IPFS

network via the Pinata pinning service API, ensuring the files were

accessible globally through the decentralized distributed hash table.

• The Target Domain (bot and Listener C2): To evaluate the command propagation over long-distance routing, the compromised host and the ephemeral exfiltration server were hosted on the AWS cloud infrastructure. Specifically, an EC2 instance runnin Ubuntu Server was provisioned in the us-east-1 region, located in Northern Virginia, USA. The bot agent continuously polled the Blockchain from this USbased server, retrieved the payloads from IPFS, executed the simulated modules, and reported back to the local Flask C2 instance.

4.1.2 Evaluation Objectives

By separating the remote operator from the bot and routing the control signals through public decentralized networks, the testbed was designed to extract realistic metrics regarding:

1. IPFS DHT Resolution Time: The time required for the bot to locate and download the encrypted payload from the peer-to-peer storage network once the CID is known.
2. End-to-End (E2E) Latency: The total time elapsed from the moment the remote operator confirms the transaction in the CLI to the exact moment the bot detects the state change and initiates the command payload.
3. Economic Impact: The empirical gas costs incurred on the L2 network for maintaining and updating the command pointer over a sustained period.

4.2 Performance Metrics and Latency Analysis

A critical factor in evaluating any C2 infrastructure is the speed at which instructions propagate from the remote operator to the infected fleet. In a traditional centralized architecture, establishing a direct TCP connection yields sub-second latency. However, decentralized architectures inherently introduce delays due to distributed consensus and peer-to-peer routing.

This section analyzes whether this latency trade-off is operationally viable for an threat actor. The empirical data was collected directly from the standard output logs of the python malware agent running on the AWS us-east-1 instance.

Table 4.1 summarizes the performance metrics extracted during the execution of two distinct operational payloads: a connectivity check and a DoS Simulation.

Table 4.1: Empirical latency metrics recorded by the Bot Agent during the transatlantic execution of two distinct command payloads.

4.2.1 IPFS DHT Resolution Time

The IPFS resolution time measures the delay between the bot successfully reading the new CID from the blockchain and the completion of the payload download from the IPFS network.

As demonstrated in Table 4.1, the resolution times were remarkably low: ∼0.43s and ∼0.56s. These results validate the decision to use a pinning service. Because the encrypted payload is pinned and pre-cached on high-availability enterprise nodes rather than relying solely on residential IPFS peers, the DHT lookup is near-instantaneous. This proves that the storage layer does not act as a bottleneck in the command distribution pipeline.

4.2.2 End-to-End (E2E) Command Propagation Latency

The E2E latency is the most significant metric. It encompasses the entire lifecycle of a command:

1. The remote operator signs and broadcasts the transaction to the Polygon sidechain.
2. The network validators process the transaction and mine it into a new block, reaching probabilistic finality.
3. The bot executes its scheduled polling routine via the public RPC node.
4. The bot detects the state change, fetches the file from IPFS, decrypts it in memory, and triggers the execution module.

The recorded E2E latencies of 5.97 and 9.13 seconds are exceptional for a fully decentralized infrastructure. This performance is primarily attributed to Polygon’s fast block times (∼2 seconds), which drastically reduce the consensus delay compared to Ethereum Mainnet (∼12 seconds).

4.2.3 The Impact of Polling Jitter

It must be noted that the variance in the E2E latency (a difference of ∼3.1 seconds between the two tests) is a direct consequence of the polling interval configured in the bot.

To evade heuristic detection and prevent self-inflicted DoS against the RPC provider, bots implement randomized sleep intervals (jitter) between queries. If a command is mined on the blockchain exactly when the bot is idle, the latency increases by the remainder of that sleep cycle. Conversely, if the transaction is mined right before the bot’s next scheduled check, the E2E latency drops to the theoretical minimum: Polygon’s block time plus the IPFS resolution time.

Ultimately, an average propagation delay of 6 to 10 seconds is entirely negligible for asynchronous malicious operations such as volumetric DDoS attacks, cryptojacking, or ransomware deployment, where real-time interactive shell access is not required.

To provide a concrete operational perspective of the system’s lifecycle, Figure 4.1 presents a raw excerpt from the standard output generated by the bot agent running on the AWS instance during the transatlantic test.

[+] New command detected!
    CID: Qmdaqntev8xry9S8RRuijZY7UDDMwJFVza4CN761fk9rq6
[*] Downloading from IPFS: https://[...].mypinata.cloud/ipfs/Qmdaq[...]
[ METRIC ] IPFS resolution time (DHT latency): 0.437 seconds
[ METRIC ] End-to-End latency (From Master to Bot): 9.13 seconds
========================================
COMMAND EXECUTION
ID: 1774435148
TYPE: CONNECTIVITY_CHECK
TARGET: 8.8.8.8
UPSTREAM C2: http://35.172.118.8:5000
========================================
[+] Running ping test...
[+] Ping completed.
----------------------------------------
[*] Sending mission report...
========================================

Figure 4.1: Raw standard output from the Bot Agent demonstrating the detection, download, and execution of a command payload.

4.3 Cost Analysis

As established in the threat model, the primary deterrent against the deployment of fully on-chain botnets is economic unfeasibility. Storing command payloads directly on an L1 network like Ethereum or paying gas fees for thousands of bots to report their status would drain an threat actor’s cryptocurrency wallet within hours.

The proposed hybrid architecture completely neutralizes this limitation by strategically delegating operations to the most cost-effective layers.

4.3.1 The Cost of Command Issuance

In this architecture, the only operation that incurs a financial cost is the execution of the setCID function on the smart sontract. Because updating the mutable pointer alters the state of the blockchain, the network requires a gas fee to prevent spam and incentivize validators.

By deploying the control layer on the Polygon sidechain rather than the Ethereum Mainnet, this cost is aggressively minimized. As previously illustrated in the blockchain explorer logs (Figure 3.2), the transaction fee required to update the CID during the PoC testing phase averaged around 0.003 POL. Given the historical market value of the native token, this translates to a fraction of a US cent (typically less than $0.005) per command.

Consequently, a remote operator could issue hundreds of new campaigns, pivot the dynamic C2 servers, or trigger emergency kill switches over an extended period, all for an aggregate operational cost of under a single dollar.

4.3.2 Zero-Cost Operations

The true economic scalability of the botnet is achieved through the offloading of bandwidth and storage:

• Gasless Polling: The most resource-intensive aspect of a botnet is maintaining communication with the infected fleet. In this PoC, bots query the blockchain using the eth call RPC method. Because this is a read-only operation that does not modify the ledger, it requires zero gas. Therefore, the remote operator pays nothing for the continuous, asynchronous polling of millions of compromised endpoints.
• Free Payload Distribution: Hosting the encrypted JSON Payloads on IPFS bypasses the exorbitant storage fees of the blockchain. Decentralized storage distributes the bandwidth load across the peer-to-peer network (and public gateways), allowing the threat actor to distribute arbitrary execution modules at effectively zero cost, regardless of how large the botnet grows.

Ultimately, the empirical data confirms that the hybrid infrastructure operates with a highly asymmetric cost model: it is virtually free for the threat actor to maintain and update, while being prohibitively expensive, or technically impossible, for authorities to dismantle.

4.4 Resilience and Security Evaluation

The fundamental premise of this thesis is that modern botnets must evolve beyond the vulnerabilities of the centralized client-server model. This section evaluates the empirical resilience of the PoC against the specific adversary capabilities defined in the threat model, specifically focusing on takedown attempts, censorship, and network analysis.

4.4.1 Takedown Resistance and Server Flux

Traditional botnets are routinely dismantled through coordinated operations that seize the physical servers or sinkhole the DGA domains used for command and control. The PoC architecture demonstrates immunity to these traditional takedown vectors through the implementation of the server flux feature.

During the experimental phase, the upstream listener C2 was hosted on an AWS EC2 instance. If an adversary were to identify the malicious traffic and terminate this instance, the control channel would remain completely unaffected. The remote operator retains the cryptographic capability to instantaneously provision a new collection server, generate a new Payload containing the updated IP address, and point the smart contract to the new CID.

Because the bots dynamically resolve the upstream destination during every polling cycle, the entire fleet would seamlessly pivot its exfiltration traffic to the new infrastructure within seconds, neutralizing the adversary’s takedown efforts with zero required changes to the underlying malware binary.

4.4.2 Censorship Resistance of the Control Layer

The control layer’s reliance on the Polygon sidechain provides a mathematically enforced defense against censorship and unauthorized modification.

• Immutability of the Pointer: Unlike centralized databases, the smart contract state cannot be altered by administrative fiat. The access control mechanism explicitly requires the remote operator’s private key signature to invoke the setCID function. Authorities cannot force the network to destroy the contract or point it to a sinkholed CID.
• Collateral Damage Mitigation: To prevent the bots from retrieving the CID, an internet service provider would have to block traffic to all public Polygon RPC nodes. Because these nodes are heavily utilized by legitimate Web3 users, decentralized finance applications, and enterprise platforms, implementing a blanket IP ban would cause unacceptable collateral damage to the legitimate digital economy.

4.4.3 Stealth and Network Evasion

From a network defense perspective, detecting the botnet’s traffic via DPI or heuristic analysis is highly challenging.

The downstream communication relies entirely on standard JSON-RPC over HTTPS directed at highly reputable domains (e.g., public blockchain infrastructure providers) and standard HTTP GET requests to IPFS gateways. This allows the bot’s polling mechanism to effortlessly blend into the massive volume of legitimate Web3 background noise.

Furthermore, while the Blockchain transactions and IPFS downloads are publicly observable, the payload confidentiality is preserved through off-chain symmetric encryption. An adversary monitoring the network can observe the CID being updated and downloaded, but cannot ascertain the target, the attack type, or the active exfiltration server without first reverse-engineering the malware agent to extract the hardcoded cryptographic key.

4.5 Analysis of On-Chain Data Access Tiers

The operational reliability of the proposed architecture depends strictly on the bot’s ability to query the blockchain state. If the communication channel between the malware and the RPC nodes is severed, the bot becomes ”orphaned”, unable to receive new instructions.

To systematically evaluate these capabilities, this section analyzes three ascending tiers of resilience for on-chain data access, comparing the trade-offs among accessibility guarantees, residual attack surfaces, and operational costs for the threat actor.

4.5.1 Tier 1: Public RPC Aggregation and Rotation

Mechanism: The bot is equipped with a hardcoded list of public RPC endpoints (e.g., Ankr, Infura, Cloudflare) or retrieves an updated list from public aggregators like Chainlist. The bot performs a round-robin or failover rotation if a node becomes unresponsive.

Accessibility Guarantee: High availability under normal conditions. As long as at least one public provider remains reachable, the bot can synchronize with the smart contract.

Residual Attack Surface: Vulnerable to ISP-level blocking. Authorities can identify and blacklist the IP addresses of major public RPC providers. Furthermore, providers can implement centralized filtering (censorship) of specific contract addresses.

Remote operator Costs: Minimal. No additional infrastructure is required. The binary footprint remains small as it only needs a standard HTTP/HTTPS client.

4.5.2 Tier 2: Dynamic Endpoint Provisioning (C2-Push)

Mechanism: In this intermediate tier, the remote operator uses the encrypted payload on IPFS to distribute a new list of private RPC nodes or custom proxies. When a bot successfully fetches a new CID, it updates its internal configuration with these new endpoints.

Accessibility Guarantee: Superior to Tier 1. The remote operator can deploy dozens of low-cost, ephemeral RPC proxies on various cloud providers, rotating them as soon as they are flagged.

Residual Attack Surface: The ”bootstrap” problem. If the initial hardcoded nodes are blocked before the bot can fetch the first CID update, the discovery mechanism fails. The defense relies on blocking the IPFS gateway.

Remote operator Costs: Moderate. Requires the management of a private proxy fleet, increasing operational complexity but maintaining a low binary footprint for the bot.

4.5.3 Tier 3: Embedded Light Client (Trustless P2P)

Mechanism: The malware agent embeds a dedicated light client. Instead of querying a centralized RPC node, the bot joins the P2P network, discovers peers, and verifies Merkle proofs to validate the state of the smart contract autonomously.

Accessibility Guarantee: Maximum resilience. This tier achieves true censorship resistance. The bot does not rely on any single provider; to stop it, an adversary would need to disrupt the entire blockchain P2P protocol globally.

Residual Attack Surface: Eclipse attacks or protocol-level DPI filtering. LEAs could attempt to isolate the bot by surrounding it with malicious peers, though this is computationally expensive and difficult to scale.

Remote operator Costs: High. The binary footprint increases significantly. The P2P traffic is noisy and more easily detectable by network-based anomaly detection systems.

4.6 Trade-off Analysis: Latency vs. Survivability

Every engineering architecture requires balancing competing constraints. In the context of adversarial infrastructure, the fundamental trade-off exists between operational speed and system survivability. The experimental results of this PoC clearly demonstrate this dichotomy.

4.6.1 The Cost of Decentralization

Traditional centralized C2 architectures, relying on direct bidirectional TCP sockets or persistent HTTP/HTTPS connections, offer near-instantaneous command execution (often in the low milliseconds). This allows for real-time interactive access, such as remote shell execution.

Conversely, the proposed hybrid architecture sacrifices this immediacy. By routing commands through the Polygon Blockchain consensus mechanism and requiring bots to resolve payloads via the IPFS decentralized network, the minimum theoretical latency is inherently constrained by block times and Polling intervals. As proven in Section 4.2, the empirical E2E latency ranges between 6 and 10 seconds

4.6.2 Operational Viability

While a 10-second delay would be unacceptable for a legitimate real-time application (e.g., high-frequency trading or live video streaming), it is entirely negligible within the threat model of a modern botnet.

The vast majority of profitable cybercriminal operations do not require real-time synchronicity. Attacks such as:

• Volumetric DoS campaigns
• Widespread ransomware deployment,
• Covert cryptojacking,
• Bulk data exfiltration,

are inherently asynchronous. Whether a bot initiates a DoS flood exactly at T0 or at T0 + 10 seconds makes absolutely no difference to the overall impact of the campaign.

4.6.3 Conclusion of the Analysis

The minor degradation in command propagation speed is a negligible price to pay for the resulting architectural invulnerability. By accepting a latency of a few seconds, the remote operator successfully trades real-time execution for a ”bulletproof” infrastructure that eliminates any SPOF, evades traditional network sinkholing, and guarantees the perpetual survival of the control channel against state-level takedown operations.

Chapter 5

Conclusions and Future Work

5.1 Ethical Considerations and Defensive Awareness

Researching and developing adversarial architectures inherently raises significant ethical questions. The design of a censorship-resistant, decentralized Command and Control infrastructure closely mirrors the creation of a sophisticated cyber weapon. However, the primary objective of this thesis is grounded in the principle of defensive awareness.

As threat actors increasingly adopt Web3 technologies to evade traditional takedown mechanisms, it is imperative for the cybersecurity community to anticipate these shifts. Studying these architectures in a controlled, academic environment allows defenders to develop effective countermeasures before such threats are deployed at scale.

5.1.1 Weaponization Gap and Code Disclosure

It is crucial to emphasize the gap between the PoC developed for this research and a fully weaponized malware strain. The provided implementation focuses exclusively on demonstrating the blockchain and IPFS routing mechanisms. It intentionally omits several critical components required for a real-world botnet, such as:

• Persistence mechanisms.
• Privilege escalation exploits.
• Advanced evasion and anti-debugging techniques.
• Lateral movement capabilities.

Due to these intentional omissions, the released codebase serves as a theoretical validation tool rather than a ready-to-use command payload. Any public disclosure of the source code will adhere to responsible disclosure guidelines, ensuring that the core routing logic is accessible for academic peer review while preventing immediate abuse by unsophisticated threat actors.

5.1.2 Defensive Mitigations

To counter the specific threats modeled in this architecture, network defenders must shift their paradigm from infrastructure disruption to behavioral analysis and endpoint security. Possible mitigation strategies include:

• Behavioral Endpoint Detection: EDR (Endpoint Detection and Response) solutions should be tuned to flag anomalous RPC polling behaviors. A background process consistently querying public blockchain nodes (via JSON-RPC) without being a recognized wallet or DeFi application is highly suspicious.
• Traffic Shaping and DPI: While blocking entire IPFS gateways or Polygon RPC nodes may cause collateral damage, organizations can implement DPI rules to detect specific payload signatures or rate-limit prolonged outbound connections to known Web3 infrastructure.
• On-Chain Heuristics: Security researchers can deploy automated monitors to track the smart contract state. By analyzing the frequency of the setCID transactions and tracing the origin of the gas fees, it may be possible to deanonymize the remote operator’s funding wallets through advanced blockchain forensics.

5.2 Summary of Contributions

This thesis proposed, implemented, and evaluated a novel hybrid Command and Control architecture designed to overcome the vulnerabilities of traditional centralized botnets and the economic unfeasibility of fully on-chain solutions.

By decoupling the control logic from data distribution, the architecture successfully leveraged the Polygon sidechain as an immutable, censorship-resistant signaling channel, and the IPFS as a zero-cost decentralized storage layer. The implementation of the proof of concept demonstrated that a remote operator can achieve total infrastructure agility through the server flux mechanism, effectively rotating ephemeral upstream C2 servers without ever losing control of the infected fleet.

The empirical evaluation confirmed that the latency introduced by the decentralized consensus mechanisms (averaging 6 to 10 seconds) represents a negligible trade-off for asynchronous malicious operations, providing the threat actor with an economically scalable, ”bulletproof” control channel that is immune to traditional domain sinkholing and server takedowns.

5.3 Current Limitations

While the PoC successfully validated the theoretical threat model, the current implementation exhibits certain operational limitations that would need to be addressed before deployment in a widespread, stealthy campaign:

• Agent Footprint: The malware agent was developed in Python. While excellent for rapid prototyping, interpreted languages require large bundled environments to run autonomously on compromised endpoint machines, significantly increasing the binary size and the likelihood of heuristic detection by endpoint security solutions.
• Gateway Dependency: The bot currently relies on public HTTP/HTTPS gateways to bridge the traditional web with the decentralized IPFS network. If these specific gateways implement strict content filtering or are temporarily unavailable, the bot’s ability to download the payload is impaired.
• RPC Trust Assumption: The agent utilizes standard JSON-RPC calls to public blockchain nodes. This implies a degree of trust in the provider. A compromised or legally coerced RPC provider could theoretically return a falsified CID, preventing the botnet from updating its state.

5.4 Future Work

To further enhance the stealth, autonomy, and resilience of the proposed architecture, several avenues for future research and development are identified:

• Compiled Implementation: Rewriting the malware agent in a low-level, compiled language such as Rust, Golang, or C++. This would drastically reduce the binary footprint, eliminate external dependencies, and allow for advanced anti-analysis and obfuscation techniques.
• Trustless Verification: Integrating light client capabilities directly into the malware binary. By downloading block headers and verifying Merkle proofs locally, the bot could achieve trustless state synchronization, rendering it completely immune to malicious RPC nodes.
• Decentralized Exfiltration: Replacing the ephemeral HTTP/HTTPS C2 server with a fully decentralized message-routing protocol (such as Waku or Swarm). This would eliminate the need for centralized VPS infrastructure entirely, allowing bots to exfiltrate telemetry and stolen data through an anonymous peer-to-peer mesh network.

5.5 Final Remarks

The continuous arms race between cybercriminals and network defenders is shifting toward a decentralized paradigm. This research demonstrates that threat actors already possess the tools and infrastructure to construct uncensorable networks at virtually zero cost, exploiting the very properties that make Web3 technologies revolutionary.

As malware inevitably transitions to public blockchains and distributed file systems, traditional defensive strategies based on IP blacklisting, domain sinkholing, and server seizures will become increasingly obsolete. The cybersecurity community must pivot its focus away from infrastructure disruption and toward endpoint behavioral analysis, zero trust architectures, and advanced memory forensics to effectively counter the next generation of decentralized threats.

Bibliography

[1] a16z Crypto. Helios: A fast, secure, and portable light client for Ethereum. Accessed 2024. → link this: https://github.com/a16z/helios

[2] S. Ali et al. “Hydras and IPFS: a decentralised playground for malware.” Journal of Computer Virology and Hacking Techniques (2020).

[3] Gregory Falco and Karen Li. “Assessing the threat of blockchain-based botnets.” 2019 IEEE International Conference on Blockchain (Blockchain) (2019).

[4] Ralph C. Merkle. “A digital signature based on a conventional encryption function.” Advances in Cryptology — CRYPTO ‘87. Springer, 1987, pp. 369–378.

[5] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008. → link this: https://bitcoin.org/bitcoin.pdf

[6] Phillip Porras, Hassen Saidi, and Vinod Yegneswaran. “An analysis of Conficker’s logic and rendezvous points.” SRI International Technical Report, 2009.

[7] Bing Han, Chuanyong Tian, and Hihan Zhang. “Deanonymizing Bitcoin Transactions via Network Traffic Analysis with Semi-supervised Learning.” arXiv preprint arXiv:2603.17261, 2026. → link this: https://arxiv.org/html/2603.17261v1