5.5 Anti-Bot and Anti-Virus

Anti-Bot: Detecting C&C Communication

The Anti-Bot blade detects communication between internal hosts and external command-and-control (C&C) infrastructure. A host that has been compromised by malware typically phones home to a C&C server to receive instructions, exfiltrate data, or download additional payloads. Anti-Bot's job is to detect that phone-home communication and stop it.

Anti-Bot uses several detection mechanisms:

• C&C reputation data from ThreatCloud — lists of known C&C IP addresses, domains, and URLs.
• DNS behavior analysis — detects DNS tunneling, fast-flux domains, and other bot-like DNS patterns.
• Behavioral heuristics — repeated connections to suspicious destinations, unusual timing patterns, and other bot fingerprints.
• Sinkhole data — when a known botnet's domain is taken over by researchers, traffic to that domain is flagged.

When Anti-Bot detects a connection to a known C&C, it can Drop, Reject, or Activate (log only). The default action in the Optimized profile is typically Drop for high-confidence C&C detections and Activate for lower-confidence ones.

Anti-Virus: Detecting Known Malware

The Anti-Virus (AV) blade detects known malware in files passing through the gateway. AV uses two complementary mechanisms:

• Signature-based detection — a local signature database on the gateway (updated from ThreatCloud) is matched against file content. This catches known malware quickly and cheaply.
• Cloud-based reputation queries — for files not matched by a local signature, the gateway queries ThreatCloud's malware reputation database. ThreatCloud aggregates telemetry from many gateways; if the file has been seen as malicious elsewhere, the gateway is told to block it.

A key CCSA distinction: AV catches known malware by signature or reputation. It does not catch zero-day malware — that is Threat Emulation's job. A common scenario tests this directly: "A user receives a never-before-seen document with a zero-day exploit — which blade catches it?" The answer is Threat Emulation, not Anti-Virus.

How the Two Blades Relate

Anti-Bot and Anti-Virus are frequently deployed together because they address different stages of the same attack. A typical compromise sequence:

1. The user receives a malicious file (caught by Anti-Virus if known, Threat Emulation if not).
2. The file executes and the host is compromised.
3. The compromised host phones home to a C&C server (caught by Anti-Bot).

Both blades are needed because prevention at step 1 is not 100% — a new or polymorphic file may evade AV, and Threat Emulation may not have time to detonate before delivery. Anti-Bot provides a second line of defense at step 3.

Configuration in the TP Profile

Both Anti-Bot and Anti-Virus are configured inside the TP profile. For each blade, you can set:

• The default action (Drop, Reject, Activate, Ask).
• Whether to inspect HTTP, SMTP, FTP, and other protocols.
• Whether to send unknown files to ThreatCloud for reputation lookup (AV) or query the C&C domain/IP reputation (Anti-Bot).
• Custom overrides for specific sources, destinations, or file types.

A typical policy uses the Optimized profile for both blades on internal user traffic and the Strict profile on guest or untrusted traffic. The CCSA does not test deep per-setting configuration; it tests the blade purpose and the recommended starting profile.

Cloud Query Model

Both blades depend on ThreatCloud queries for unknown items:

• AV queries the cloud for unknown file reputations.
• Anti-Bot queries the cloud for unknown domain/IP reputations.

If the gateway cannot reach ThreatCloud (for example, in an air-gapped environment), the blades fall back to their local signature/reputation cache. New threats that arrived since the last successful update will not be detected. The CCSA expects you to recognize that ThreatCloud connectivity is required for full AV and Anti-Bot effectiveness, and that offline gateways rely on cached data.

Logging and Forensics

Both blades generate detailed logs. Anti-Bot logs include the C&C indicator (domain, IP, URL), the infected host, and the bot name (where known). AV logs include the malware name, the file name, the file hash, and the source/destination. These logs feed SmartEvent reports showing top infected hosts, top malware families, and trends over time — useful for incident response after a compromise is detected.

For the CCSA, the key forensic concept is that an Anti-Bot detection on a host indicates the host is likely already compromised. The correct response is incident response: isolate the host, investigate, and remediate — not simply to drop the connection and move on, because other C&C channels may exist that have not yet been detected.

What These Blades Do Not Do

Neither Anti-Bot nor Anti-Virus detects unknown zero-day malware — that is Threat Emulation's role. Neither detects malicious file content that is active but not malware (e.g., a phishing page with no malware payload) — that is URL Filtering's role. Neither detects attack patterns in traffic — that is IPS's role.

Common CCSA Scenarios

Typical Anti-Bot and Anti-Virus questions:

• Identify which blade detects C&C communication (Anti-Bot).
• Identify which blade catches known malware by signature (Anti-Virus).
• Identify which blade catches zero-day malware (Threat Emulation, not AV).
• Recognize the dependency on ThreatCloud for reputation queries.
• Recognize that an Anti-Bot detection implies a compromised host requiring incident response.

A representative scenario: a host on the internal network makes regular connections to an unfamiliar overseas IP. Anti-Bot fires. What does this mean, and what should the administrator do? The host is likely compromised and phoning home; the administrator should treat it as an incident, isolate the host, and look for additional C&C channels — not merely drop the connection.