Zendesk relay spam shows support systems can be abused as trusted senders

At a glance

What this is: The article argues that support ticket systems can be abused as trusted senders, with Zendesk-style public ticket creation enabling relay spam through legitimate return addresses.

Why it matters: This matters because identity and access teams often overlook support portals and helpdesk workflows, even though they can become trust-amplifying systems that bypass email and spam controls.

👉 Read Swarmnetics' analysis of Zendesk relay spam and support system abuse

Context

Support ticket systems are designed to preserve customer reachability, but that same openness can create a trust boundary problem when unverified users can trigger messages from a known platform identity. In this case, the primary issue is not credential theft but abuse of the support workflow as a delivery mechanism, which makes the security question one of who is allowed to originate trusted communications.

For IAM and GRC teams, the intersection is governance of externally reachable workflows, not just user authentication. If verified access is optional, the support platform becomes a low-friction relay for nuisance traffic and potential phishing delivery, which means identity controls need to be applied to support channels as well as employee systems.

Key questions

Q: How should security teams handle anonymous ticket submission in support systems?

A: Allow anonymous ticket submission only when the business need is clear and the trust boundary is tightly controlled. If a support platform can generate trusted outbound mail from an unauthenticated form, verify users before acceptance or separate public intake from trusted communications. Otherwise, attackers can use the platform as a relay for spam, noise, or helpdesk targeting.

Q: Why do support systems create identity and trust risk even without account compromise?

A: Because the risk comes from workflow trust, not just login compromise. A public support form can trigger messages that recipients treat as legitimate because they originate from a known service. That means the support system itself becomes an identity-adjacent channel, and governance has to cover who may initiate trusted communications.

Q: What do organisations get wrong about spam abuse in helpdesk tools?

A: They often focus on content filtering and ignore the origin control. If the platform accepts unverified submissions, the sender reputation can be abused even when the payload is harmless. The key question is whether the workflow should exist at all without authentication, not whether the email gateway can catch every message.

Q: Who is accountable when a public support workflow is abused for trusted-message spam?

A: Accountability usually sits with the owners of the support platform, the identity team, and the security function together. The practical failure is leaving a trusted outbound path open to anonymous input. Governance frameworks should require clear ownership for support-channel access, exception approvals, and abuse monitoring.

Technical breakdown

How relay spam exploits trusted support workflows

Relay spam works by submitting a support request through a system that is allowed to send receipt or update messages from a trusted domain. If the platform accepts arbitrary return addresses, the attacker can make the message appear to come from an ordinary support interaction even though the source is unauthenticated. The abuse depends on policy, not code execution: the platform is behaving as designed, but the design assumes benign use. This is why seemingly minor convenience settings can become an abuse primitive when they sit on the boundary between public input and trusted outbound mail.

Practical implication: require verified-user gating or equivalent trust checks before any support workflow can generate externally delivered messages.

Why support systems can bypass spam and security filters

Email and security gateways often treat messages from established support platforms as lower risk because the sender reputation is strong and the content looks operational. That trust can be exploited when a receipt or case update is triggered by a public form rather than an authenticated user. Even if the payload is only annoying text, the path matters because the platform itself becomes the trusted relay. Where attachments and URLs are blocked, the immediate impact is narrower, but the trust abuse still consumes attention and can be used for pressure, noise, or helpdesk targeting.

Practical implication: tune mail security rules so trusted-origin messages are not exempt from abuse detection when they originate from public workflows.

Why verified ticket creation is the controlling boundary

The most effective control is not downstream filtering but restricting ticket creation to verified users or known accounts. That shifts the boundary from open submission to authenticated engagement, which reduces the attacker’s ability to weaponise the platform’s reputation. In governance terms, this is an access control decision for a customer-facing system, not merely an operational preference. The default setting matters because optional hardening is often left untouched, and that leaves a trusted communication path open to bulk abuse.

Practical implication: make verified ticket submission the default for externally reachable support systems and review any exception process explicitly.

Threat narrative

Attacker objective: The attacker’s objective is to exploit trusted support infrastructure to generate spam, disrupt operations, and possibly redirect attention toward helpdesk staff or recipients.

1. Entry occurs through a public support form that accepts ticket submissions without user verification.
2. Escalation comes from the platform sending receipt or update messages from a trusted sender identity, which helps the abuse pass ordinary filtering.
3. Impact is message flooding, helpdesk disruption, and a potential pathway for targeted phishing or operational noise against support teams.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Support portals are identity systems in disguise. When a ticketing platform can originate trusted outbound messages from an unauthenticated public form, it is functioning as an identity-bearing communication channel, not just a service desk. That means access governance has to extend beyond employee directories and privileged accounts to include externally reachable support workflows. Practitioners should treat support origin controls as part of IAM and messaging trust.

Convenience defaults create standing trust. The problem here is not that attackers discovered a novel exploit chain, but that optional verification left a trusted send path open to anyone who knew how to submit a ticket. That is a governance failure because the platform’s trust posture was broader than the business need. Support systems should be configured so the smallest-privilege communication path is the default, not an opt-in.

Relay spam is an abuse pattern, not a one-off nuisance. A bulk spam campaign can be low in technical sophistication and still expose weak controls around sender reputation, workflow gating, and support escalation. The real lesson is that trust abuse often looks operational rather than malicious until volume or targeting changes. Organisations should assume that any public workflow that generates trusted messages will eventually be tested by abuse at scale.

Named concept: trusted workflow relay abuse. This article illustrates how public-facing business workflows can be turned into trusted delivery channels when identity checks are weak or optional. The control gap is not only email filtering but the absence of governance over who may trigger a trusted communication path. Teams should catalogue these workflows alongside other identity-adjacent attack surfaces and reduce their implicit trust.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a broader view of how identity exposure cascades across real incidents, see 52 NHI Breaches Analysis for root-cause patterns and governance lessons.

What this signals

Trusted workflow relay abuse is a useful lens for security programmes because it sits between identity governance and messaging security. If a public workflow can generate trusted communication, the control question is no longer only who can log in, but who can cause the system to speak on behalf of the business. Teams should map those paths now and treat them as part of their identity-adjacent attack surface.

The governance implication is straightforward: support systems, case portals, and contact forms need explicit ownership, abuse thresholds, and exception handling. Where ticket creation remains open, the organisation should expect noise campaigns and social engineering attempts to test that boundary. A support platform that can be used as a relay is a trust problem first and a spam problem second.

For practitioners looking to tighten the boundary, the most useful reference point is the NHI abuse pattern catalogue in 52 NHI Breaches Analysis, which shows how small trust gaps become repeated operational failures. The lesson is to reduce standing trust in public workflows before an attacker turns them into a delivery channel.

For practitioners

• Restrict ticket creation to verified users Disable anonymous ticket submission where the support function does not require it, and define an exception process for any customer-facing use case that truly depends on public intake.
• Separate public intake from trusted outbound messaging Ensure that receipt and case-update messages generated from public forms do not inherit the same trust treatment as authenticated support interactions, especially in mail filters and SOC review logic.
• Review support workflows as identity-adjacent assets Inventory which portals, helpdesk tools, and case systems can originate messages, then apply the same governance review you would use for externally facing accounts and service identities.
• Harden detection for volume abuse patterns Alert on sudden spikes in ticket creation, repeated submissions from varied addresses, and unusual subject-line patterns that indicate relay spam or automated nuisance traffic.
• Train helpdesk staff on trust-boundary abuse Make sure support teams recognise typosquatted domains, repeated complaint patterns, and suspicious ticket content so they do not amplify the abuse through manual follow-up.

Key takeaways

• Support systems can become trusted relays when anonymous input is allowed to trigger outbound messages.
• The real risk is governance failure at the workflow boundary, not just weak spam filtering or low-sophistication nuisance traffic.
• Verified ticket creation and explicit trust controls are the main levers for reducing abuse of helpdesk platforms.

Key terms

• Trusted Workflow Relay: A trusted workflow relay is a business process that can be used to originate messages or actions that recipients interpret as legitimate. In security terms, the risk is not only account compromise but abuse of the system’s reputation and trust boundary.
• Support System Abuse: Support system abuse is the misuse of helpdesk or ticketing workflows to create noise, social engineering opportunities, or operational disruption. It often exploits convenience settings, weak verification, or overly trusted outbound communication paths rather than technical vulnerabilities.
• Verified User Gating: Verified user gating requires a user or sender to authenticate before they can trigger a privileged workflow. In support systems, it narrows the attack surface by preventing anonymous parties from causing trusted messages or actions to be generated.

What's in the full analysis

Swarmnetics' full analysis covers the operational detail this post intentionally leaves for the source:

• How the relay spam pattern works across specific support platforms and message flows.
• The exact default settings that make anonymous ticket creation possible in common helpdesk deployments.
• The practical trade-offs between public intake convenience and verified-user gating.
• The vendor's observations on which message characteristics were most likely to slip through spam controls.

👉 Swarmnetics' full post covers the support workflow abuse pattern, trust-boundary weaknesses, and mitigation options.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management through a practitioner lens. It helps security teams apply identity controls consistently across service accounts, support workflows, and other trust-bearing systems.