TL;DR: FBI guidance on malicious traffic distribution systems shows how attackers use redirect chains, victim filtering and hidden destinations to bypass perimeter controls and deliver phishing, malware or ransomware access paths, according to Appgate. The security problem is not just deceptive traffic, but the assumption that visibility and static network rules can still define trust.
NHIMG editorial — based on content published by Appgate: analysis of the FBI advisory on malicious traffic distribution systems and the access architecture implications
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams reduce the impact of malicious redirect chains?
A: They should make access depend on identity, device context and explicit entitlement instead of on whether a user arrives from a trusted-looking path.
Q: Why do malicious TDS campaigns matter to IAM teams?
A: Because they turn access into an outcome of deception, not just authentication.
Q: What do organisations get wrong about perimeter-based web security?
A: They often assume that blocking known bad destinations is enough, but TDS hides the final destination behind intermediate infrastructure and selective delivery.
Practitioner guidance
- Reduce exposed resource discoverability Hide protected services from unauthenticated scanning and probing so a successful redirect does not automatically reveal the internal estate.
- Bind access to identity and context Require identity verification, device posture and resource entitlement checks before any session can reach internal assets.
- Tighten least privilege for remote access Limit each authenticated user to the smallest set of applications or services needed so stolen credentials cannot open broad network paths.
What's in the full article
Appgate's full analysis covers the operational detail this post intentionally leaves for the source:
- FBI advisory mapping to specific redirect and filtering patterns seen in malicious TDS campaigns.
- Appgate ZTNA deployment details for hiding protected resources from unauthenticated discovery.
- Practical notes on combining identity checks, device posture and segmentation in access policy.
- Control mapping between FBI recommendations and ZTNA capabilities for implementation teams.
👉 Read Appgate's analysis of malicious traffic distribution systems and ZTNA →
Malicious TDS campaigns: what they mean for Zero Trust and access?
Explore further
Perimeter visibility is no longer a sufficient trust boundary: Malicious TDS campaigns exploit the gap between where a user begins and where the payload is actually delivered. That means firewall-centric thinking overstates the defender’s ability to see and block the real destination. The practitioner conclusion is straightforward: trust has to be decided at the point of access, not inferred from the path the user took.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility, according to The State of Non-Human Identity Security.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a redirected session leads to ransomware access?
A: Accountability sits with the organisation that controls exposed access, identity policy and segmentation, not just with the user who clicked. If a redirected session can still reach sensitive systems, the access architecture is too permissive. Security and identity owners should be able to show what the session could reach before and after authentication.
👉 Read our full editorial: Malicious traffic distribution systems expose the limits of perimeter trust