Two major incidents in six months - Crunchyroll and Discord - and one vector: Zendesk. Not zero-day in code, not RCE, not something beautiful. Ordinary compromising the agency account through an outsourcer.
In March 2026, Crunchyroll confirmed the leak. According to Have I Been Pwned, 1 195 684 email addresses. The statement of the attacker about the wider PII set has not yet been confirmed. Six months earlier, the same trick went off on Discord: a group identified in the reports of Rescana and BleepingComputer as Scattered Lapsus$ Hunters allegedly held access to Zendesk-Instanis for about 58 hours. According to the attackers - 1.6 TB data, 8.4 million tickettes, 5.5 million affected users. The figures are not confirmed by independent sources; Discord has acknowledged the incident, but has challenged the scale.
One blind monitoring area. Below - a complete execution of the data breach through Zendesk, specific detection rules for SIEM and checklist, which can be transmitted to the team right now.
Business logic: why break the support system
Zendesk is not a “just a ticket system”. This is a repository with direct access to PII: names, emails, phones, payment data, IP addresses. In the case of Discord, there are also scans of passports and driver's licenses loaded to verify the age. Zendesk is integrated with Okta, Slack, internal client-company API. According to Rescan, integration with internal Discord systems allowed millions of APIs to be used to use an internal database through a support platform. Zendesk worked as a proxy for data that Discord itself never exhibited outward. More details - in our the Cyber Attack Investigation Guide.
Financial motivation is straightforward: according to Rescan (requires independent verification), the SLH group allegedly demanded $5 million from Discord, later reducing to $3.5 million. Negotiations, according to the same data, were held from September 25 to October 2, 2025. Discord refused to pay. For the attacker, helpdesk is at the same time a data collection point and a pressure lever: the threat of publishing tickets with passports creates pressure, which is not the usual theft of password he hashes.
Regulatory context: The leakage of scans of public certificates and payment data falls under the GDPR (fine up to 4% of global turnover), CCPA and 152-FZ. For a company whose support service processes user documents, compromising helpdesk is an incident of a category "critical" according to any classification standard.
Kill chain of support system: from agent to exfilter
Compromise of an agency account through a BPO-provider
The key point of both incidents: the attack did not exploit the vulnerability in the Zendesk code. According to BleepingComputer and Rescana, in the case of Discord, the attackers compromised the account of the employee of the outsourcing provider (BPO). Supply Chain Compromise (T1195) + Valid Accounts (T1078) - classics.
The attackers gained access to Zenbar - the internal Zendesk tool, through which agents perform administrative operations: search for users, disconnect MFA, viewing phones and email. According to Rescan, the attackers provided screenshots of access to the Kolide (device trust) and Okta (IAM) panels - this indicates the capture of an active session or theft of the agent's account data.
At the same time, according to the vendor threat intelligence reports (requires independent verification), financially motivated groups use similar tactics: they send BPO employees to phishing pages that mimic Okta and Zendsk, steal the contents of the exchange buffer to bypass the MFA and register their own devices for access. Domains follow the pattern <org>.zendesk-support<##>.com.
A separate story is an architectural vulnerability described by security researchers: in the absence of SPF/DKIM/DKIM/DARC on the Zendesk client’s email domain, allows you to access the ticketbook via spoofed email. Zendesk closed the hole, but the incident showed that the comprometisation vector of helpdesk is wider than only phishing on the BPO.
The context for the pentester: if you are testing an organization with Zendesk and BPO support on the project - the entry point is not in the Zendesk itself, but in the process of authenticating the outsourcer. Check if there are FIDO2/WebAuthn BPO agents or only standard OTP, interceptable phishing kit.
Mass collection of data from ticket (T1213)
After receiving an agency access, Data from Information Repositories (T1213, Collection) In the case of Discord, the attackers collected:
• ~1.5 TB of attachments to takets (scans of documents, screenshots)
• ~100 GB of tickette decoctions - about 8.4 million records
• Data ~580 000 users with payment information (purchase type, the last four card numbers, purchase history)
• About 70 000 images of public licenses (at the request of the attackers; Discord confirmed a significantly smaller number, the exact figure is not disclosed)
Collection Mechanics: Zendesk API allows an authorized agent to perform requests for endpoints /api/v2/tickets, /api/v2/search, /api/v2/ticket_audits. If there is an API token or OAuth session of the agent there is no architectural limit on the volume of unloading. Rate limits Zendesk (according to the documentation - up to 700 queries / min for Core API on the Enterprise-plan, but Search API and Incremental Exports - only 10 queries / min, with each request of Incremental Export returns a large amount of data) is designed to protect against overload, and not from authorized exfiling.
Here’s a blind spot: the difference between “agent sees one ticket” and “the agent unloads millions of records” at API level is not controlled by default.
Extilting via HTTPS (T1567)
Exfiltration Over Web Service (T1567): The data goes away through the standard HTTPS - the same channel through which the Zendesk API operates normally. For network monitoring, it looks like legitimate support agent traffic. According to FireCompass, the attackers used automated scripts with API tokens from compromised accounts.
Dwell time in the Discord case - about 58 hours (according to Rescan). The Crunchyroll data leak was also found not instantaneously. Why does SOC not see helpdesk compromise?
Zendesk Audit Trail is not integrated into SIEM. Most organizations do not send Zendesk logs to Splunk, Elastic, or MaxPatrol SIEM. Zendesk maintains its own Audit Log (Settings -> Account -> Audit Log), but it records only administrative changes, not read-requests for tickets. Massive data unloading there simply does not get there. For a spread read detection, you need Access Log (Enterprise) or network monitoring. If your SOC doesn’t get these events, you’re blind to that vector.
There is no baseline API activity. The typical load of the agent depends on the company - baseline is built individually. When an account starts making thousands of API requests per hour, it’s an anomaly. But without baseline, SOC has no threshold for the alert. With the permissible hundred requests per minute through one account, you can unload millions of tickets in two days - this is exactly what happened in the Discord case.
Legitimate user-agent and channel. Queries via Zendesk API with a valid token are coming from a predictable user-agent over HTTPS. For proxy or WAF, this is a normal job. An anomaly can only be caught by volume, geolocation or pattern - and this requires a correlation that does not exist.
BPO = uncontrolled endpoint. An outsourcing employee works from his device, possibly from another country. Device trust (Kolide) and IAM (Okta) had to stop the attack - but in the Discord case, the attackers also got access to these panels. Either complete session capture or compromising the device.
Invasion detection in SIEM: Correlation rules for Zendesk
Practical detection rules that close the described blind zones. Examples for Splunk SPL - adapt to your stack (Elastic KQL, MaxPatrol SIEM, KUMA, RusIEM).
Detection of the anomalous volume of API-requests. Pre-introvertising Zendesk Audit Log in SIEM via API polling endpoint /api/v2/audit_logs or webhook:
Code:
index=zendesk sourcetype=zendesk:audit source_type="ticket" action IN ("exported","update","destroy")
| bucket _time span=1h
| stats count as api_calls by actor_id, src_ip, _time
| where api_calls > 500
| eval severity=if(api_calls>5000,"critical","high")
The threshold of 500 requests per hour is the starting point. Adjust to your baseline after 30 days of data collection. For Elastic - similar logic through zendesk.audit.action with aggregation by user.id and source.ip.
Detection of geolocation anomalies. The second critical signal is the login of the agent from atypical geolocation. In terms of D3FEND - User Geolocation Logon Pattern Analysis (D3-UGLPA) According to Google Threat Intelligence Group, UNC6783 used an anonymizing services, creating a characteristic pattern of geolocation change:
Code:
index=zendesk sourcetype=zendesk:audit event_type="login"
| iplocation src_ip
| stats dc(Country) as country_count values(Country) as countries by actor_id
| where country_count > 1
The BPO agent usually works from the same country. The user from the VPN exit in another region is an alter.
Detector of atypical administrative actions. Monitoring of operations that a regular agent does not do: disabling MFA, massive search for users, access to the endpoint of bulk export. In the Discord case, attackers via Zenbar turned off the MFA and looked for users by phone. Correlation rule: if one account in a short period performs both mass export of tickets and administrative actions - critical severity, immediate blocking of the session.
Detection of abnormal upload/download ratio. D3FEND Per Host Download-Upload Ratio AnalysisD3-PHDURA) The agent who downloads gigabytes of investments, but does not give anything in response - the pattern of exfiltration. Monitor the amount of outgoing traffic on the Zendesk CDN hosts (*.zendesk.com) in relation to a specific user.
Binding to Sigma: for T1078 (Valid Accounts) in SigmaHQ - 114 rules, including azure_ad_auth_sucess_increase.yml for the detection of abnormal growth of successful authentications. Adapt logic to Zendesk SSO via your IdP (Okta, Azure AD, Keycloak). For T1213 (Data from Information Repositories) - 12 rules, including opencanary_git_clone_request.yml. But the rules of T1213 in SigmaHQ are focused on honeypot events (OpenCanary) and GitHub audit. For Zendesk, you will have to write your own detection rule based on volumetric API metrics.
In March 2026, Crunchyroll confirmed the leak. According to Have I Been Pwned, 1 195 684 email addresses. The statement of the attacker about the wider PII set has not yet been confirmed. Six months earlier, the same trick went off on Discord: a group identified in the reports of Rescana and BleepingComputer as Scattered Lapsus$ Hunters allegedly held access to Zendesk-Instanis for about 58 hours. According to the attackers - 1.6 TB data, 8.4 million tickettes, 5.5 million affected users. The figures are not confirmed by independent sources; Discord has acknowledged the incident, but has challenged the scale.
One blind monitoring area. Below - a complete execution of the data breach through Zendesk, specific detection rules for SIEM and checklist, which can be transmitted to the team right now.
Business logic: why break the support system
Zendesk is not a “just a ticket system”. This is a repository with direct access to PII: names, emails, phones, payment data, IP addresses. In the case of Discord, there are also scans of passports and driver's licenses loaded to verify the age. Zendesk is integrated with Okta, Slack, internal client-company API. According to Rescan, integration with internal Discord systems allowed millions of APIs to be used to use an internal database through a support platform. Zendesk worked as a proxy for data that Discord itself never exhibited outward. More details - in our the Cyber Attack Investigation Guide.
Financial motivation is straightforward: according to Rescan (requires independent verification), the SLH group allegedly demanded $5 million from Discord, later reducing to $3.5 million. Negotiations, according to the same data, were held from September 25 to October 2, 2025. Discord refused to pay. For the attacker, helpdesk is at the same time a data collection point and a pressure lever: the threat of publishing tickets with passports creates pressure, which is not the usual theft of password he hashes.
Regulatory context: The leakage of scans of public certificates and payment data falls under the GDPR (fine up to 4% of global turnover), CCPA and 152-FZ. For a company whose support service processes user documents, compromising helpdesk is an incident of a category "critical" according to any classification standard.
Kill chain of support system: from agent to exfilter
Compromise of an agency account through a BPO-provider
The key point of both incidents: the attack did not exploit the vulnerability in the Zendesk code. According to BleepingComputer and Rescana, in the case of Discord, the attackers compromised the account of the employee of the outsourcing provider (BPO). Supply Chain Compromise (T1195) + Valid Accounts (T1078) - classics.
The attackers gained access to Zenbar - the internal Zendesk tool, through which agents perform administrative operations: search for users, disconnect MFA, viewing phones and email. According to Rescan, the attackers provided screenshots of access to the Kolide (device trust) and Okta (IAM) panels - this indicates the capture of an active session or theft of the agent's account data.
At the same time, according to the vendor threat intelligence reports (requires independent verification), financially motivated groups use similar tactics: they send BPO employees to phishing pages that mimic Okta and Zendsk, steal the contents of the exchange buffer to bypass the MFA and register their own devices for access. Domains follow the pattern <org>.zendesk-support<##>.com.
A separate story is an architectural vulnerability described by security researchers: in the absence of SPF/DKIM/DKIM/DARC on the Zendesk client’s email domain, allows you to access the ticketbook via spoofed email. Zendesk closed the hole, but the incident showed that the comprometisation vector of helpdesk is wider than only phishing on the BPO.
The context for the pentester: if you are testing an organization with Zendesk and BPO support on the project - the entry point is not in the Zendesk itself, but in the process of authenticating the outsourcer. Check if there are FIDO2/WebAuthn BPO agents or only standard OTP, interceptable phishing kit.
Mass collection of data from ticket (T1213)
After receiving an agency access, Data from Information Repositories (T1213, Collection) In the case of Discord, the attackers collected:
• ~1.5 TB of attachments to takets (scans of documents, screenshots)
• ~100 GB of tickette decoctions - about 8.4 million records
• Data ~580 000 users with payment information (purchase type, the last four card numbers, purchase history)
• About 70 000 images of public licenses (at the request of the attackers; Discord confirmed a significantly smaller number, the exact figure is not disclosed)
Collection Mechanics: Zendesk API allows an authorized agent to perform requests for endpoints /api/v2/tickets, /api/v2/search, /api/v2/ticket_audits. If there is an API token or OAuth session of the agent there is no architectural limit on the volume of unloading. Rate limits Zendesk (according to the documentation - up to 700 queries / min for Core API on the Enterprise-plan, but Search API and Incremental Exports - only 10 queries / min, with each request of Incremental Export returns a large amount of data) is designed to protect against overload, and not from authorized exfiling.
Here’s a blind spot: the difference between “agent sees one ticket” and “the agent unloads millions of records” at API level is not controlled by default.
Extilting via HTTPS (T1567)
Exfiltration Over Web Service (T1567): The data goes away through the standard HTTPS - the same channel through which the Zendesk API operates normally. For network monitoring, it looks like legitimate support agent traffic. According to FireCompass, the attackers used automated scripts with API tokens from compromised accounts.
Dwell time in the Discord case - about 58 hours (according to Rescan). The Crunchyroll data leak was also found not instantaneously. Why does SOC not see helpdesk compromise?
Zendesk Audit Trail is not integrated into SIEM. Most organizations do not send Zendesk logs to Splunk, Elastic, or MaxPatrol SIEM. Zendesk maintains its own Audit Log (Settings -> Account -> Audit Log), but it records only administrative changes, not read-requests for tickets. Massive data unloading there simply does not get there. For a spread read detection, you need Access Log (Enterprise) or network monitoring. If your SOC doesn’t get these events, you’re blind to that vector.
There is no baseline API activity. The typical load of the agent depends on the company - baseline is built individually. When an account starts making thousands of API requests per hour, it’s an anomaly. But without baseline, SOC has no threshold for the alert. With the permissible hundred requests per minute through one account, you can unload millions of tickets in two days - this is exactly what happened in the Discord case.
Legitimate user-agent and channel. Queries via Zendesk API with a valid token are coming from a predictable user-agent over HTTPS. For proxy or WAF, this is a normal job. An anomaly can only be caught by volume, geolocation or pattern - and this requires a correlation that does not exist.
BPO = uncontrolled endpoint. An outsourcing employee works from his device, possibly from another country. Device trust (Kolide) and IAM (Okta) had to stop the attack - but in the Discord case, the attackers also got access to these panels. Either complete session capture or compromising the device.
Invasion detection in SIEM: Correlation rules for Zendesk
Practical detection rules that close the described blind zones. Examples for Splunk SPL - adapt to your stack (Elastic KQL, MaxPatrol SIEM, KUMA, RusIEM).
Detection of the anomalous volume of API-requests. Pre-introvertising Zendesk Audit Log in SIEM via API polling endpoint /api/v2/audit_logs or webhook:
Code:
index=zendesk sourcetype=zendesk:audit source_type="ticket" action IN ("exported","update","destroy")
| bucket _time span=1h
| stats count as api_calls by actor_id, src_ip, _time
| where api_calls > 500
| eval severity=if(api_calls>5000,"critical","high")
The threshold of 500 requests per hour is the starting point. Adjust to your baseline after 30 days of data collection. For Elastic - similar logic through zendesk.audit.action with aggregation by user.id and source.ip.
Detection of geolocation anomalies. The second critical signal is the login of the agent from atypical geolocation. In terms of D3FEND - User Geolocation Logon Pattern Analysis (D3-UGLPA) According to Google Threat Intelligence Group, UNC6783 used an anonymizing services, creating a characteristic pattern of geolocation change:
Code:
index=zendesk sourcetype=zendesk:audit event_type="login"
| iplocation src_ip
| stats dc(Country) as country_count values(Country) as countries by actor_id
| where country_count > 1
The BPO agent usually works from the same country. The user from the VPN exit in another region is an alter.
Detector of atypical administrative actions. Monitoring of operations that a regular agent does not do: disabling MFA, massive search for users, access to the endpoint of bulk export. In the Discord case, attackers via Zenbar turned off the MFA and looked for users by phone. Correlation rule: if one account in a short period performs both mass export of tickets and administrative actions - critical severity, immediate blocking of the session.
Detection of abnormal upload/download ratio. D3FEND Per Host Download-Upload Ratio AnalysisD3-PHDURA) The agent who downloads gigabytes of investments, but does not give anything in response - the pattern of exfiltration. Monitor the amount of outgoing traffic on the Zendesk CDN hosts (*.zendesk.com) in relation to a specific user.
Binding to Sigma: for T1078 (Valid Accounts) in SigmaHQ - 114 rules, including azure_ad_auth_sucess_increase.yml for the detection of abnormal growth of successful authentications. Adapt logic to Zendesk SSO via your IdP (Okta, Azure AD, Keycloak). For T1213 (Data from Information Repositories) - 12 rules, including opencanary_git_clone_request.yml. But the rules of T1213 in SigmaHQ are focused on honeypot events (OpenCanary) and GitHub audit. For Zendesk, you will have to write your own detection rule based on volumetric API metrics.
