Користувачі електронної пошти по всьому світу останніми днями фіксують незвичну хвилю спаму, який надходить не з підозрілих доменів, а з легітимних адрес служб підтримки компаній, що працюють на платформі Zendesk. Листи приходять десятками й навіть сотнями, мають тривожні або абсурдні теми, але зазвичай не містять явних шкідливих вкладень чи фішингових посилань. Попри це, масштаб і спосіб розсилки викликають серйозну занепокоєність фахівців з кібербезпеки.
Спам через Zendesk: коли законна транзакційна пошта перетворюється на канал атаки
Перші повідомлення про масову розсилку з’явилися в соцмережах приблизно 18 січня: користувачі почали скаржитися на «лавину» автоматичних відповідей від різних служб підтримки. Формально ці листи є коректними нотифікаціями helpdesk-систем, але фактично використовуються як інфраструктура для relay-спаму — масової розсилки через легітимного посередника.
Ключовий аспект інциденту полягає в тому, що відправниками виступають реальні компанії та сама платформа Zendesk із високою репутацією доменів і належно налаштованими SPF/DKIM/DMARC-записами. Для більшості поштових шлюзів це виглядає як звичайна транзакційна пошта, а не як масова спам-кампанія, тому фільтри майже не спрацьовують.
Як працює схема relay-спаму через helpdesk-платформи
Зловживання відкритими формами створення тикетів
Багато організацій дозволяють створювати звернення в Zendesk без реєстрації користувача і без обов’язкового підтвердження email. З погляду клієнтського сервісу це зручно: достатньо вказати адресу пошти й текст запиту.
Зловмисники використовують цю логіку як безкоштовний поштовий шлюз. Вони автоматизовано надсилають запити через відкриті форми, підставляючи в поле email списки сторонніх адрес. У результаті Zendesk генерує тикет і миттєво розсилає службові підтвердження на кожну введену адресу. Саме ці системні нотифікації і стають потоком relay-спаму.
Чому листи проходять крізь антіспам-захист
Сучасні антиспам-рішення значною мірою орієнтуються на репутацію домена, історію відправника та криптографічні записи (SPF, DKIM, DMARC). У випадку Zendesk і великих брендів усі технічні атрибути листів виглядають бездоганно: інфраструктура давно відома, доменам довіряють, показники скарг на спам зазвичай низькі.
Таким чином, маємо класичний приклад relay-спаму: атакуючий не розсилає листи напряму, а підключається до шанованої платформи як до «ретранслятора» з позитивною історією відправлень. Для користувача це виглядає як звичайне повідомлення від служби підтримки реальної компанії.
Які компанії постраждали та чи йдеться про злам
У кампейні зафіксовано використання служб підтримки таких брендів, як Discord, Tinder, Riot Games, Dropbox, CD Projekt (2k.com), Maya Mobile, NordVPN, освітні платформи, а також окремі державні структури США (зокрема відомства штату Теннессі). Це охоплює розважальні сервіси, SaaS-рішення, VPN-провайдерів і держсектор.
Важливо, що наразі немає ознак компрометації інфраструктури цих компаній. Йдеться не про злам, а про некоректно обмежений публічний функціонал: системи роблять саме те, для чого були налаштовані, але без достатнього рівня антиспам- та антибот-захисту.
Тематики листів: емоційний тиск і соціальна інженерія
Частина звернень оформлена як нібито офіційні запити від правоохоронних органів або попередження про блокування контенту. Інші обіцяють безкоштовний Discord Nitro, містять заголовки типу «Терміново, допоможіть!» або активно використовують Unicode-символи, різні мови й жирне форматування, щоб привернути увагу у перевантаженій скриньці.
Навіть без явного шкідливого коду такі листи створюють інформаційний шум, виснажують увагу користувачів і підвищують імовірність імпульсивних дій: переходу за посиланнями, відповіді на повідомлення, які здаються нагальними чи офіційними. Це робить канал relay-спаму потенційно привабливим для майбутніх цільових фішингових атак.
Реакція Zendesk і рекомендації щодо захисту від спаму
Окремі постраждалі компанії, зокрема Dropbox і 2K, вже підтвердили факт зловживання їхніми helpdesk-системами й порадили користувачам ігнорувати листи техпідтримки, якщо вони не ініціювали звернення. Організації наголошують, що не виконують чутливих операцій із акаунтами без додаткової верифікації власника.
Zendesk оголосив про впровадження додаткового моніторингу, обмежень на масове створення тикетів та механізмів виявлення аномальної активності з подальшим блокуванням підозрілих кампаній. Платформа рекомендує клієнтам:
• Обмежити створення тикетів верифікованими користувачами — запровадити підтвердження email або аутентифікацію через акаунт.
• Прибрати необов’язкові плейсхолдери та довільні поля, де можна вільно змінювати тему листа й адресу відправника.
• Увімкнути захист від ботів: CAPTCHA, rate limiting для IP і доменів, ліміти на кількість звернень за одиницю часу.
Стратегічні ризики relay-спаму через helpdesk-платформи
За даними різних галузевих звітів з кібербезпеки, значна частина глобального поштового трафіку (нерідко понад половину) все ще становить спам. Використання легітимних helpdesk-платформ небезпечне тим, що додає атакам ореол довіри завдяки бренду компанії та репутації її домену. Сьогодні такі листи переважно безпечні за вмістом, але той самий вектор легко може бути використаний для високоточних фішингових та BEC-атак (Business Email Compromise).
Масова розсилка через системи підтримки також дозволяє атакуючим тестувати актуальність адрес, поведінку користувачів і реакцію поштових фільтрів. Це дані, які підвищують ефективність наступних цільових кампаній проти окремих організацій або їхніх клієнтів.
Для бізнесу цей інцидент є чітким сигналом: будь-який публічний канал взаємодії з клієнтами — форма зворотного зв’язку, чат, helpdesk, API — має розглядатися як потенційний вектор атаки, а не лише традиційні поштові сервери чи корпоративні веб-сайти. Компаніям варто провести ревізію налаштувань своїх систем підтримки, увімкнути багаторівневий захист від зловживань і регулярно аналізувати журнали активності. Користувачам доцільно уважніше ставитися до автоматичних нотифікацій: перевіряти звернення через особистий кабінет або офіційний додаток, не переходити за посиланнями з неочікуваних листів і позначати підозрілі повідомлення як спам.
