FortiGuard Labs’ latest TrickBot analysis is a useful reminder that “normal” infrastructure traffic can still carry command-and-control when defenders only inspect the obvious protocols. The sample Fortinet analyzed is a Windows TrickBot variant that moves away from the familiar HTTP-based C2 pattern and instead wraps its operator traffic inside DNS queries and responses.

That matters because DNS is usually allowed everywhere. Workstations, servers, and cloud workloads all need name resolution, so many environments treat DNS as background noise instead of a telemetry source. For small businesses and government contractors, that is exactly the kind of blind spot attackers look for: a protocol that is trusted, high-volume, and rarely reviewed with the same rigor as web, VPN, or endpoint logs.

What FortiGuard observed

FortiGuard reported that the captured samples were 64-bit Windows executables with shared behavior across different file hashes, indicating a related TrickBot campaign. The malware uses several analysis-resistance techniques, including runtime string decryption, dynamically calculated constants, and API resolution through hash-based lookups.

The persistence mechanism is straightforward but effective. The malware creates a Windows scheduled task that runs at startup and repeats every few minutes. In the sample Fortinet analyzed, the task was disguised as an automatic Wireshark update. The malware also stores task and executable path information in NTFS Alternate Data Streams, helping it maintain state and avoid creating duplicate scheduled tasks.

The more important defensive lesson is the C2 channel. FortiGuard observed the malware sending malformed DNS queries through a public resolver. The variant encrypts command data, hex-encodes it, splits it into DNS-label-sized chunks, and appends it to a controlled domain. Responses can also carry data back through IPv4 address fields, with indexing logic to reassemble payloads even if intermediate resolvers reorder addresses.

Why this matters for SMBs and government contractors

DNS tunneling is not new, but it remains dangerous because many environments still lack a clear DNS control plane. Endpoint agents may detect the payload eventually, but DNS telemetry can provide earlier warning: unusual query length, repeated malformed queries, suspicious subdomain entropy, direct use of public resolvers, or a host suddenly generating resolver traffic inconsistent with its role.

For organizations that support federal customers, handle regulated data, or operate lean IT teams, the takeaway is not “block DNS.” The takeaway is to make DNS observable and governed. If every endpoint can freely query any external resolver, defenders lose one of the best choke points for spotting stealthy malware communications.

Defensive takeaways

  • Centralize DNS resolution. Force workstations and servers to use approved internal resolvers. Block direct outbound DNS to public resolvers except from designated infrastructure.
  • Alert on tunneling patterns. Look for long labels, high-entropy subdomains, abnormal query volume, repeated NXDOMAIN behavior, and unusual A-record response sets.
  • Monitor scheduled tasks. Baseline legitimate scheduled tasks and alert on new tasks running from user-writable paths, temporary directories, removable drives, or odd “updater” names.
  • Inspect Alternate Data Streams where practical. ADS usage is not always malicious, but malware using ADS for configuration or persistence metadata is a useful hunting lead.
  • Restrict resolver egress at the firewall. DNS should be treated like a controlled service, not a default-anywhere outbound protocol.
  • Correlate DNS with endpoint context. A single weird query may be noise. Weird DNS plus new scheduled-task persistence from the same host is a much stronger signal.

Bulwark Black assessment

This TrickBot variant reinforces a simple principle: malware does not need exotic infrastructure when enterprise defaults are permissive. If DNS is unmonitored and every endpoint can reach external resolvers directly, attackers get a covert channel for free.

The practical move is to treat DNS as part of the security stack. Centralized resolver logs, egress controls, endpoint-to-DNS correlation, and scheduled-task monitoring are achievable controls for small teams. They do not require a massive SOC to start producing value, and they directly reduce the stealth window for malware families that hide inside trusted network protocols.

Source: FortiGuard Labs — Inside a TrickBot Variant Using DNS Tunneling for C2