Question
How can I combat spam submitted via web service?
Answer
The primary goal of spammers is to use your triggers to pass spam content to other users through placeholders. Zendesk automatically suppresses certain placeholders when certain criteria are met. For more information, see the article: Understanding placeholder suppression rules.
However, if you have customized triggers, you may still have placeholders that pass content of the ticket to the end user upon ticket creation, for example, {{ticket.title}}.
Instructions
Step 1: Remove placeholders that spammers target
Update your account's version of the Notify requester and CCs of received request trigger.
- If the trigger in your account that notifies requesters and CCs of received request doesn't have it yet, add the condition Current user | Is | (end user)
- Under Actions, refer to the Email subject and Email body fields. Remove any reference to the placeholder {{ticket.title}} or any other placeholder that renders content.
Removing this placeholder renders your trigger useless to spammers since it will no longer share their spam content with recipients. This step doesn't immediately stop the flow of spam tickets but prevents spammers from reaching your customers, and you should eventually stop seeing spam come in.
Step 2: Make sure you have a trigger for agent-created tickets
If your agents create tickets on behalf of end users, for example, sending out proactive emails, you need a trigger that notifies users of the content of those tickets but doesn't allow spammers to do the same.
Newly created Support accounts already have the default Notify requester of new proactive ticket trigger enabled in their accounts. However, older accounts may need to create one from scratch.
Temporarily blocking email domains using the blocklist
While the above recommendations will protect your account from further spam, it will not immediately stop ticket creation. If you want to block ticket creation regardless of channel, use the blocklist feature with the blocklist modifier suspend: or reject: prepended to the domain.
blacklist: reject:randomspammer@gmail.com suspend:qq.com
For more information on spam prevention on other channels, see the article: Spam prevention resources.
99 Comments
If I add the current user is end user, will that mean that people who submit tickets from the widget that aren't signed in, won't get a message that they opened a ticket?
Also, why is Zendesk not alerting anyone proactively to the need for these changes?
Hi Celia Johnson,
Thanks for your reply.
Adding the current user is end user refers to the person making the last comment -- Essentially you're narrowing the trigger for only end users, to prevent both the notify requester of received request (the altered trigger) and the notify requester of proactive request (which provides the first comment from agents) at the same time. This will remain the same regardless of channel.
"why is Zendesk not alerting anyone proactively to the need for these changes?"
We actually made the announcement of default trigger changes three months back, which should have show under your admin settings within news. To make sure you don't miss these, I highly recommend subscribing to the Product announcement section: https://support.zendesk.com/hc/en-us/articles/360029449913-Changing-Triggers-to-prevent-spam
-- As for proactively emailing --
We've been sending small cohorts to affected users via email, though we have not widespread sent an alert out (beyond the announcement above). We're looking into more effective methods of sending out these messages and hope to have a widespread solution coming shortly.
Apologies for the inconvenience overall -- If you have any additional questions, please don't hesitate to reach out to support, and we'd be glad to assist.
has this been fixed yet? we just got hit with a ton of spam API tickets, asking us to remove the placeholders is not a good solution, it's been months since you guys posted this! still not fixed?! that's unacceptable!!
We have been receiving a bunch of spam API tickets, beginning earlier this afternoon.
We also started getting hit earlier today. How can we be certain which trigger is being triggered? Why can't Zendesk detect these attacks on their own website?
Currently being affected by this issue. Zendesk Support has been in touch and confirmed that this is an API Request endpoint issue under investigation.
Hi all -
Thank you for your comments. This issue is currently being worked on, and we will provide updates here as we have them available. I've added your cases to our internal problem ticket on the issue.
update: we are putting some temporary blocks in place to combat the spam; you should begin to see the issue subside shortly.
Hi, we are also under this attack. I've made all the suggested changes to our trigger. Nicole S. could you also help investigate and stop the influx of tickets via the API endpoint?
We are still under attack. We've received 4 spam messages this morning.
We started to receive a number of spam messages, too - starting 01/03/20. We are getting these entered via the Zendesk anonymous post method of ticket creation:
https://developer.zendesk.com/rest_api/docs/support/requests#create-request
Anonymous request
At my organization, all of our tickets are created from email, the Zendesk web form, or via a follow up ticket. Since we don't create any new tickets via any API, I'm able to create a trigger that looks for any created tickets via this method, tag them as such, solve them and bypass any further action. They still get created, but they immediately get buried and don't cause issues. I add a tag called "zendesk_spam" so I can keep an eye on them....
Specifically, I do this (with some additional variations) and make this my first trigger. This way, I don't have to remove all the placeholders as Zendesk suggests above. Of course, this only works because we don't use the API method to create tickets....
This is not an authoritative answer but merely a question regarding Jim's tactic -- Could you just set a single Channel condition of "Is Web service (API)" instead of "Is not Email" and "Is not Web form"? And are you just closing the ticket if meeting those conditions?
I chose the negative check in case other unexpected spam starts arriving via other channels we don’t use. I’m solving them now ( and not closing ) simply to check the triggers and attributes I’m assigning to make sure all is working as intended.
This is still affecting us as well. I made the changes described above and that seemed to help for a few hours last night, but the spammers are back in full force today. We've received dozens of messages over the last 24 hours.
Fortunately we have a fairly consistent customer base with many users across few domains which allowed us to take the first crack at stopping this by making the change to "Ask users to register" along with whitelisting our customer base. This has the net effect of automatically putting the spam into the Suspend queue where I can periodically delete it and none of our techs see it (we also push ticket updates to Slack and the spam was clogging that view as well). While at the same time not inhibiting our customer base to force start registering in order to submit issues. So far this is working well.
To that end, I may give Jim's technique a try as well since my method has a few undesirable corners.
Rather than these workarounds, how about an actual fix?
Please add an option to disable unauthenticated/anonymous API ticket submissions only, without affecting other channels.
Please also keep me alerted to the status of this fix, we are also getting hit hard today.
Same situation for us. Lots of unwanted tickets coming in.
We have received roughly 50 of these messages in the last 12 hours. I would prefer a system wide solution rather than workarounds that will eventually reduce spam.
This wasn't an issue for us until last night.
We have been hit heavily within the last 24 hours with spam-tickets submitted via the API. They are very similar, and the going rate is around 10 per hour. Very annoying.
My company is also experiencing an ongoing attack.
Apparently, Jim and I had a similar idea. Currently, as temporary fix, I have set up a similar trigger that looks like this;
We have customized all of our auto-reply notifications so that they will not fire if the ticket has the "notified" tag. This trigger is in the first position and is set to apply the "notified" tag to any tickets that match the above conditions, as well as assign the ticket to my agent account.
15 new spam tickets have come in since I set this up, and all of them have been assigned to my user agent account and prevented from sending out a notification.
Thankfully, I mostly do internal tech stuff, so my zendesk getting filled with spam isn't an issue. After the attack we can comb through them and see if any legitimate messages got caught up in it.
For now, I feel like adjusting your auto-reply tickets to follow a similar system is a better work around than this nonsense.
Hopefully this will teach zendesk that they need to fix this exploit.
3 months later the issue is still not fixed, this is not good enough! My support desk has been hammered all day!
Instead of messing around releasing new half baked products how about you keep the core support desk solution secure!
Remember many of your customers have been with you for many years, it appears currently the ZD management team has lost sight of the vision and mission!
2 important products 1)Support 2)Guide
Everything else is obviously a distraction!
We have implemented all the suggestions but are still being hit with a high volume of tickets, please provide a solution asap
We are too have been impacted by a high volume of spam tickets via the API. Surely Zendesk should have the knowledge and tools to stop these calls to their own API.
Another account experiencing this issue. Have Implemented suggested fixes. Crossing Fingers.
We are impacted also and nothing suggested works. 7+ months to fix an issue is unacceptable! This has been my experience with ZenDesk for years. The support is awful, and the problems are many. So ridiculous for a company that supports tech support people!
We are also affected by the issue since yesterday (Jan 4). Spam coming in via API. I removed placeholders from the default Notify requester of received request trigger, no other triggers with placeholders in place. This didn't help.
We were hit by a similar spam attack also some months ago and removing the placeholders didn't help either back then. Zendesk support was informed back then and also now. Very disappointing that there isn't a solution yet.
Since it sounds like they're all Instagram related- I was thinking of setting up a trigger that just finds the word Instagram mentioned in the ticket and stops any response and then marks it as spam.... any downside to doing that? We sure as heck don't have any legit customers mentioning Instagram.
Anyone really good at writing triggers that can suggest the best practice way to do it if it seems like a decent idea?
edit - so a small number of customers do mention their instagram address in their email signatures (narcissists lol) so maybe the trigger should look for "instagram" and "audit" since they all seem to mention that...
All mine seem to have bitbiz.xyz included in the text... so I can do something like this
can someone help me figure out what action to take after that? Is there a way to mark it spam in the trigger?
Edit: I found this idea https://support.zendesk.com/hc/en-us/community/posts/115007252947-Looking-to-better-deal-with-high-number-of-spam-messages
seems good- send em to a dark hole and never reply... just need someone to help make sure we set this up correctly and share here so everyone can copy it.
Please sign in to leave a comment.