Trusted Tools, Weaponized: How Zendesk Support Systems Were Turned into a Global Spam Cannon

Expanded Overview

This activity represents a systematic abuse of customer support tooling as a spam delivery platform, rather than a compromise of traditional IT systems. The attackers identified that Zendesk’s design prioritizes accessibility and ease of customer contact, which becomes a liability when controls are relaxed or left at default.

The attackers essentially turned customer support portals into mail relays that benefit from:

Excellent sender reputation
Pre-existing trust relationships
High delivery success rates
Branded legitimacy

This campaign is notable not for sophistication, but for efficiency and scale.

Attacker Objectives

Based on observed behavior, the objectives appear to be:

Mass spam distribution
Phishing delivery with high inbox placement
Brand impersonation without compromise
Low-cost, low-risk campaign execution
Evasion of traditional spam infrastructure takedowns

There is no evidence the attackers attempted lateral movement, privilege escalation, or data exfiltration.

Detailed Attack Lifecycle

1. Reconnaissance Phase

Attackers likely:

Enumerated public Zendesk portals using search engines
Identified /hc/en-us/requests/new or equivalent endpoints
Tested form behavior manually
Checked whether email verification or CAPTCHA was enforced
Measured submission tolerance before throttling

This phase appears slow and deliberate to avoid detection.

2. Weaponization Phase

Once a vulnerable portal was identified:

Ticket templates were created
Content was generalized for reuse
URLs were embedded (often shortened or redirected)
Language variants were prepared for different regions

The same message body was often reused across hundreds or thousands of tickets.

3. Delivery Phase (Primary Abuse)

Delivery occurred via:

Automated POST requests to Zendesk ticket endpoints
Randomized requester email addresses (victims)
Cloud-based IP infrastructure
Rotating user-agent strings

Zendesk then:

Accepted the ticket
Generated confirmation or response emails
Delivered messages directly to the victim inbox

At this point, the attacker no longer needed to control delivery.

4. Exploitation Phase (User Interaction)

Actual exploitation depended entirely on:

User trust in the brand
Email legitimacy
Sense of urgency in the message

Typical lures included:

Account warnings
Security alerts
Payment issues
Access suspension notices

5. Post-Delivery Behavior

After delivery:

Attackers monitored link clicks and traffic
Domains were rotated if flagged
Campaigns shifted to new Zendesk portals when blocked

There is no indication attackers attempted follow-up interaction via Zendesk replies.

Payload Deep Dive

Message Content

No personalization beyond brand name
Generic language
Poor grammar in some cases
Reused phrases across multiple organizations

URLs

Redirect chains (2–4 hops)
Often first hop was a legitimate service
Final landing pages varied per campaign wave

Attachments

Rare
Mostly avoided to prevent AV triggering

Why Traditional Security Missed This

Emails originated from trusted Zendesk infrastructure
SPF, DKIM, and DMARC all passed
No malware attachment
Content was text-based
URLs often newly registered and low reputation, not yet blocked

This made the campaign resistant to signature-based detection.

Expanded Indicators of Compromise

Zendesk Platform Indicators

Large volumes of tickets from unrelated requester domains
Identical message bodies across tickets
Tickets created outside regional business hours
Sudden spikes followed by silence (batch campaigns)

Email Indicators

Support emails received without prior interaction
“Ticket created” confirmations the user never initiated
External URLs not matching brand domain
Lack of personalization

Infrastructure Indicators

Cloud IP ranges
Short-lived IP reuse
High request concurrency
Uniform request sizes

Detection Strategy

Detection should focus on behavior, not payload.

Key questions:

Is ticket volume normal?
Are requesters known?
Is content repeated?
Is submission speed human-like?

Detection Rules

Below are platform-agnostic Sigma-style rules written for SOC and SIEM teams. These are intentionally flexible.

Sigma Rule 1: Abnormal Zendesk Ticket Creation Volume

title: Zendesk Excessive Unauthenticated Ticket Creation
id: 8f9a3a71-b1f4-4c21-a2d6-zen-spam-001
status: experimental
description: Detects spikes in unauthenticated Zendesk ticket submissions indicative of automated abuse.
author: Internal SOC
logsource:
  category: webserver
  product: zendesk
detection:
  selection:
    http_method: POST
    url|contains:
      - "/requests"
      - "/hc/"
  condition:
    selection | count() > 100
timeframe: 5m
level: high

Sigma Rule 2: Repeated Zendesk Ticket Content

title: Zendesk Repeated Ticket Message Content
id: 2b4c7d98-zen-spam-002
status: experimental
description: Detects repeated identical ticket content submitted across multiple requester emails.
author: Internal SOC
logsource:
  category: application
  product: zendesk
detection:
  selection:
    ticket_body|contains:
      - "verify"
      - "account"
      - "suspended"
  condition:
    selection | count_distinct(requester_email) > 20
timeframe: 10m
level: high

Sigma Rule 3: Zendesk Ticket Submission from Cloud Infrastructure

title: Zendesk Ticket Creation from Cloud IP Ranges
id: 6d1e9f22-zen-spam-003
status: experimental
description: Detects Zendesk ticket submissions originating from cloud hosting providers.
author: Internal SOC
logsource:
  category: network
  product: zendesk
detection:
  selection:
    src_ip|startswith:
      - "34."
      - "35."
      - "52."
      - "104."
  condition: selection
level: medium

Sigma Rule 4: Zendesk Ticket Creation with External URLs

title: Zendesk Ticket Containing External URLs
id: c5b0e211-zen-spam-004
status: experimental
description: Detects support tickets containing external URLs not associated with the organization.
author: Internal SOC
logsource:
  category: application
  product: zendesk
detection:
  selection:
    ticket_body|contains:
      - "http://"
      - "https://"
  filter:
    ticket_body|contains:
      - "companydomain.com"
  condition: selection and not filter
level: high

Threat Hunting Playbook

Hunt 1: Historical Abuse

Search 90 days of ticket data
Identify first instance of repeated content
Track expansion to other portals

Hunt 2: Behavioral Outliers

Find requester emails never seen before
Correlate submission time vs normal customer behavior
Identify unusually short submission intervals

Hunt 3: Infrastructure Correlation

Pivot on source IPs
Check reuse across multiple brands
Identify shared automation fingerprints

Defensive Recommendations (Expanded)

Platform Hardening

Require email verification
Enforce CAPTCHA
Disable anonymous ticket creation
Implement per-IP and per-ASN rate limits

SOC Integration

Ingest Zendesk logs into SIEM
Create alerting thresholds
Add dashboards for ticket health metrics

Customer Communication

Clarify official support processes
Warn users about unsolicited support emails
Encourage reporting suspicious messages

Final Takeaway

This campaign highlights a recurring security blind spot: business systems are often trusted by default. The attackers exploited process trust, not technical flaws.

The lesson is clear — any system that sends email on behalf of your brand is part of your attack surface.