A Note Before We Begin
This article is not an attack on Darktrace. Darktrace is a capable network detection and response platform that provides genuine value to organizations that deploy it correctly. What follows is a technical discussion of the inherent limitations that apply to all behavioral analysis tools, including Darktrace, Vectra, ExtraHop and every other NDR platform on the market.
These are not vulnerabilities in Darktrace. They are inherent limits of behavioral analysis. Understanding them is the first step toward building a defense that accounts for them.
Blind Spot 1: Encrypted Tunnels
Darktrace analyzes network traffic by observing patterns, metadata and payload content where available. When traffic is encrypted, Darktrace can still see connection metadata: source and destination IPs, port numbers, packet sizes, timing patterns and TLS certificate information.
What it cannot see is the payload. An encrypted tunnel carrying command-and-control traffic looks identical to an encrypted tunnel carrying legitimate HTTPS traffic at the metadata level. If the attacker uses a valid TLS certificate, connects to a cloud provider IP address and maintains connection timing that resembles normal browsing, the encrypted tunnel becomes effectively invisible to behavioral analysis.
This is not a configuration problem. It is a physics problem. You cannot inspect what you cannot decrypt. Organizations that do not perform SSL/TLS interception at a proxy have a structural blind spot that no amount of behavioral modeling can close.
Attackers know this. Modern command-and-control frameworks like Cobalt Strike, Sliver and Mythic default to encrypted HTTPS channels specifically because they know NDR tools struggle with encrypted content inspection.
Blind Spot 2: MAC Spoofing with Legitimate Prefixes
Darktrace tracks devices on the network partly through MAC addresses. When a new MAC address appears, Darktrace flags it as a new device and begins building a behavioral baseline. This is a useful detection mechanism for rogue devices.
However, MAC addresses are trivially spoofable. An attacker who clones the MAC address of an existing authorized device, or uses a MAC address with a legitimate vendor prefix (Dell, HP, Cisco), can appear as a known or expected device type. Darktrace's device tracking becomes less reliable when the attacker's device looks like it belongs.
Combined with hostname cloning (discussed below), MAC spoofing allows an attacker to blend into the existing device population. The behavioral baseline for the cloned identity absorbs the attacker's traffic because it looks like traffic from a device that already has an established pattern.
Blind Spot 3: Low-Throughput DNS Tunnels
DNS tunneling is a well-known exfiltration technique. Data is encoded into DNS queries and sent to an attacker-controlled DNS server. Darktrace can detect DNS tunneling when the volume of DNS queries significantly exceeds normal levels or when query patterns exhibit obvious encoding characteristics.
The limitation emerges at low throughput. An attacker who exfiltrates data at a rate of a few kilobytes per hour, spreading queries across multiple subdomains and maintaining normal query timing intervals, generates DNS traffic that is statistically indistinguishable from legitimate DNS resolution.
This is a classic signal-to-noise problem. Your network generates thousands of DNS queries per minute. A handful of additional queries carrying encoded data in subdomain labels are lost in that volume. Darktrace's behavioral model would need to flag individual DNS queries as anomalous, which would generate an unmanageable number of false positives.
Low-and-slow exfiltration is exactly the technique that sophisticated attackers prefer. They sacrifice speed for stealth, knowing that behavioral detection systems are calibrated for bulk anomalies rather than individual events.
Blind Spot 4: Traffic Mimicking Normal Patterns
Behavioral analysis works by establishing a baseline of normal activity and alerting on deviations. This means any attacker behavior that falls within the range of normal activity goes undetected.
Practical examples:
- An attacker who accesses file shares during business hours, at a pace consistent with normal user access, does not trigger volume-based anomaly detection
- Lateral movement that follows the same paths as legitimate administrative access blends with baseline traffic
- Data exfiltration through cloud storage services that are already used by the organization (OneDrive, Google Drive, Dropbox) appears as normal cloud usage
- Command-and-control traffic that beacons at intervals consistent with legitimate software update checks mimics expected patterns
This is the fundamental paradox of behavioral detection. It catches unusual behavior. It misses behavior that is designed to look usual. Sophisticated attackers study their target's normal patterns and operate within those boundaries. This is exactly what we simulate during ShadowTap validation engagements.
Blind Spot 5: Cloned Hostnames
Darktrace uses hostnames as part of its device identification and behavioral modeling. An attacker who sets their device's hostname to match an existing device on the network (for example, cloning the hostname of a printer, a conference room display or a rarely used workstation) can inherit some of the behavioral baseline of that device.
More importantly, cloned hostnames create confusion during incident investigation. When an alert fires, the security team sees a familiar hostname and may dismiss it as a false positive. The attacker gains time while the team investigates whether the alert is real or noise.
In environments with poor asset inventory hygiene, cloned hostnames are particularly effective. If the security team does not have a definitive list of every device and its expected hostname, they cannot quickly distinguish a clone from the original.
What This Means for Your Defense
None of these blind spots mean Darktrace is a bad product. They mean Darktrace, like every detection tool, has boundaries. The question is whether you know where those boundaries are in your specific environment.
That is what independent validation is for. Not to prove your tools fail, but to map exactly what they see and what they miss. With that map, you can make informed decisions about compensating controls, configuration changes and architectural improvements.
At Sherlock Forensics, we built ShadowTap to test these blind spots in real production environments. We do not test in a lab. We test in your network, with your traffic, against your actual Darktrace deployment. The result is a validation report that tells you exactly where your coverage stands.