Botnet architecture: topology, roles, and coordination

A network of components has more than one structure

When studying botnet architecture, distinguish which components can communicate, which components are trusted to issue work, and which components actually perform that work. A graph of connections answers only the first question. It does not establish command authority, message authenticity, or execution.

This lesson models relationships using four invented node names. It never opens a connection, discovers a host, distributes work, or invokes a remote action. The model supports a narrow architectural question: which nodes become unreachable in this particular graph if one node is removed?

Compare two static graphs

centralized = {
    "hub": {"a", "b", "c"},
    "a": {"hub"}, "b": {"hub"}, "c": {"hub"},
}
ring = {
    "hub": {"a", "c"}, "a": {"hub", "b"},
    "b": {"a", "c"}, "c": {"b", "hub"},
}


def remaining_edges(graph, removed):
    return {
        node: peers - {removed}
        for node, peers in graph.items()
        if node != removed
    }


assert remaining_edges(centralized, "hub")["a"] == set()
assert remaining_edges(ring, "hub")["a"] == {"b"}
print("static graph checks passed")

Read what the model establishes

Removing the hub isolates the leaves in the first graph. In the ring model, A retains a relationship with B. Those are statements about the declared edges, not predictions about a live network. The code does not model time, transport failures, authentication, message forwarding, or whether a surviving node can perform any useful operation.

Central coordination and peer relationships are useful architectural distinctions, but neither topology alone describes a malware family. A deployment can also have roles that are absent from the graph, such as a component that prepares data without participating in the modeled communication.

Propagation is a separate mechanism

A botnet relationship does not explain how a component arrived at a node. Likewise, a component capable of replication does not automatically imply a particular command topology. Keep initial execution, propagation, coordination, and endpoint capability separate in the component map.

A concrete example of the need to inspect capabilities is CISA's Truebot advisory, which describes collection and exfiltration activity. That report is evidence about the discussed activity; it does not establish the topology of this invented graph or every other botnet.

Exercise

After removing hub, does a remaining edge prove that node A will receive or execute a command? Which additional contracts would be needed to answer that question?

Check your understanding

No. An edge only represents a relationship in the model. You would need the message protocol, authority rules, forwarding behavior, and the receiving component's execution contract. Graph connectivity should not be presented as proof of successful coordination.