The FBI's TDS Advisory Highlights Why Reducing Exposure and Enforcing Identity-Based Access Matter

The FBI's recent public service announcement on malicious traffic distribution systems (TDS) highlights a security challenge that extends beyond phishing, malware delivery or malicious advertising. It points to a broader architectural issue: Attackers are becoming more effective at manipulating the path between users and the resources they are trying to reach.

Traffic distribution systems (TDSs) are legitimate routing technologies that can direct users to different destinations based on attributes such as location, device, browser, operating system or referral source. Cybercriminals use the same concept to redirect users through a chain of intermediate infrastructure before delivering phishing pages, fraudulent login portals, malware or other malicious content. The FBI warns that these systems can help attackers bypass traditional firewall rules, hide the final malicious destination, filter victims and gain access to victim networks for ransomware or other financial crimes.

That sequence matters because it exposes a weakness in traditional access models. Many organizations still rely heavily on perimeter visibility, firewall rules, VPN exposure, user training and static controls to reduce risk. Those controls remain useful, but malicious TDS campaigns show why they may not be sufficient on their own. When attackers can obscure the destination, selectively deliver payloads and weaponize compromised websites, organizations benefit from reducing the value of exposed infrastructure and enforcing access based on identity, context and least privilege.

This is where Zero Trust Network Access (ZTNA) becomes more than a remote access tool. It becomes part of a broader strategy to change the conditions attackers depend on.

What the FBI advisory is warning about

The FBI advisory describes a multi-stage threat chain:

1.    Attackers drive users into a malicious redirection path. Phishing emails, SEO poisoning, fraudulent advertisements, promotions, downloads or compromised legitimate websites push users into the chain. In some cases, cybercriminals compromise websites by brute forcing weak administrative passwords or exploiting outdated plugins and themes, then modifying the website code to redirect visitors into the malicious TDS.
2.    The redirection chain bypasses traditional firewall defenses. Rather than sending victims directly to a known malicious domain, the TDS routes traffic through intermediate nodes that obscure the final destination. This makes the activity harder to trace and harder to block using static network indicators.
3.    Attackers filter potential victims. A malicious TDS can collect information about the visitor's IP address, operating system, location, device and browser. Based on those attributes, it can decide whether to deliver a payload, show harmless content or avoid exposing the campaign to researchers and unintended targets.
4.    The user is delivered to the final destination. This may be a phishing page, malware download, fraudulent website or other exploit path. The FBI warns that this activity can lead to access into victim networks and that access may later be sold to ransomware groups or other cybercriminals.

This is not only a user-awareness problem. It is also a visibility, exposure and access control problem.

Why traditional perimeter controls struggle

Firewalls and URL filtering are designed to enforce rules against known or observable destinations. But TDS infrastructure is intentionally built to complicate that visibility. The final malicious destination may be hidden behind a chain of redirects. The content delivered may vary by geography, device, browser or other attributes. A security analyst may see benign content, while a targeted user sees a credential harvesting page or malware prompt.

This does not mean firewalls, web application firewalls (WAFs), endpoint monitoring, patching or user awareness are obsolete. In fact, the FBI recommends many of those controls. But it does mean organizations should not assume those controls can fully compensate for exposed infrastructure or broad network access.

Attackers do not need to defeat every control if they can trick a user, steal a credential, install malware or gain an initial foothold. Once they have access, the real question becomes: What can they reach? That is the access architecture question.

How AppGate ZTNA changes the exposure model

AppGate ZTNA is designed around a different assumption: Protected resources should not be broadly visible or reachable by default. Using Single Packet Authorization, AppGate ZTNA helps hide protected infrastructure from unauthorized discovery before a connection is established. This reduces the ability of unauthenticated users to scan, enumerate or probe protected systems.

That capability addresses a related risk raised by the FBI advisory: Attackers are increasingly effective at obscuring malicious paths and bypassing controls that depend on visibility alone. A malicious TDS can manipulate where a user goes, but it does not automatically make protected enterprise resources visible or reachable. AppGate ZTNA reduces attack surface by making access conditional before connectivity is established.

This is important because many attacks depend on exposure. If a service is visible, attackers can test it. If it responds, they can probe it. If it is reachable with stolen credentials, they can attempt access. AppGate ZTNA reduces that opportunity by keeping protected resources inaccessible until trust requirements are met.
In other words, AppGate ZTNA does not make malicious redirects disappear. It helps reduce what attackers can do in the event that a redirect succeeds.

It is worth noting one important nuance: the AppGate Portal appliance is a notable exception and may be internet-exposed over HTTPS, so “hidden infrastructure” should be understood as applying to protected resources behind the access architecture rather than every component in every deployment.

Identity and context matter more than network path

The FBI advisory notes that malicious TDS chains can bypass traditional firewall rules by hiding the final destination behind intermediary nodes. That is a reminder not to rely too heavily on network-path assumptions alone.
AppGate ZTNA enforces access based on identity, context, entitlement and device posture rather than broad network location. Access decisions can consider who the user is, what role they have, what device they are using, where the request originates, whether the device meets posture requirements and what resource the user is entitled to access.

This is a more defensible mapping than assuming every TDS-routed session will automatically present an anomalous posture. A malicious redirect does not necessarily change the user's device posture by itself. But the key point is that AppGate ZTNA does not grant access simply because a user presents a credential or arrives from a particular network path. Access can be governed by policy conditions.

That distinction matters. A stolen password captured through a phishing page should not automatically equal broad network access. A user operating from an unmanaged or unhealthy device should not receive the same access as a known user on a compliant device. A contractor, employee, administrator or third-party vendor should not inherit broad access simply because they authenticated once.

Zero Trust turns access into a policy-driven decision.

Reducing the value of compromised credentials

The FBI warns that malicious TDS campaigns can deliver phishing pages and malware, leading to stolen credentials, compromised accounts and access that may later be sold to ransomware groups. This is one of the most important implications for enterprise security teams.

Credential compromise is no longer a rare edge case. It is a predictable outcome of modern social engineering, phishing infrastructure, malware and account takeover campaigns. The goal should be to prevent as much compromise as possible while also reducing the damage when compromise occurs.

AppGate ZTNA is designed to support that second goal by limiting access to only the resources a user is explicitly authorized to reach. Through identity-based access and network-segmentation, users do not receive broad network connectivity. They receive specific access to specific resources based on policy.

That means a compromised credential does not automatically open the network. In deployments where these controls are configured, an attacker may still face device posture checks, contextual policy enforcement, multi-factor authentication (MFA) requirements and least-privilege access boundaries. If access is granted, network-segmentation helps restrict lateral movement.

This directly supports the broader ransomware concern raised in the advisory. Initial access becomes less valuable when the environment does not provide broad reachability.

Mapping the FBI recommendations to AppGate ZTNA

The FBI recommends user caution, software updates, WAFs, stronger login security, endpoint monitoring, user training, CMS audits and changes to risky file associations. AppGate ZTNA does not replace all of those controls, nor should it be positioned that way. The stronger argument is that ZTNA complements those measures by enforcing access where identity, device and resource authorization matter most.

The result is not a single magic control, but a stronger access architecture.

The bigger shift: From blocking destinations to reducing exposure

The FBI's TDS advisory reinforces a broader security reality. Attackers are not only building better phishing pages. They are building better routing infrastructure, better evasion logic and better victim filtering. They are learning how to exploit the assumptions behind traditional perimeter controls.

Organizations should respond by strengthening the controls the FBI recommends, but they should also ask a more foundational question: How much infrastructure is visible, reachable and dependent on static trust?

AppGate ZTNA helps answer that question by reducing discoverability of protected resources, enforcing identity-based access, evaluating context and device posture and limiting access to what each user actually needs. That architectural shift is increasingly valuable as attackers become better at hiding their paths and monetizing access.
The FBI advisory is a reminder that security teams cannot rely on visibility alone when attackers are actively working to obscure it. A stronger strategy is to reduce exposure by design while layering identity, context and least-privilege access controls.

A note on disclosure

The FBI's advisory ends with a simple ask: Report it. That request matters more than it might seem. TDS infrastructure works because it is reusable. The same redirection chains, compromised admin panels and phishing kits get repurposed across many victims. Every organization that stays quiet about an intrusion gives that infrastructure more runway.
Security teams often hesitate to disclose incidents, whether from reputational concern, uncertainty about scope or simple bandwidth. But threat intelligence sharing works the same way herd immunity does: it only helps the community if enough organizations participate. Filing a report with IC3 or a local FBI field office does not just close out an internal incident. It gives investigators the pattern data needed to take down TDS infrastructure before the next organization walks into it.

Reducing exposure and reporting compromise are not separate strategies. They are two parts of the same defense-in-depth mindset.

Explore how AppGate ZTNA helps organizations reduce infrastructure exposure, enforce identity-based access and limit the blast radius of compromised credentials.