Zendesk jako „spam relay”: jak globalna fala spamu przejęła systemy ticketowe firm - Security Bez Tabu

Zendesk jako „spam relay”: jak globalna fala spamu przejęła systemy ticketowe firm

Wprowadzenie do problemu / definicja luki

W połowie stycznia 2026 r. użytkownicy na całym świecie zaczęli raportować setki wiadomości e-mail, które wyglądały jak legalne powiadomienia z działów wsparcia znanych firm. Źródłem okazały się instancje Zendesk skonfigurowane tak, by przyjmować zgłoszenia od niezweryfikowanych (anonimowych) nadawców, a następnie automatycznie wysyłać potwierdzenia utworzenia zgłoszenia na podany adres. Atakujący wykorzystują to jako formę relay spamu: podszywają się pod „zainteresowanego klienta”, wpisują cudzy adres e-mail i „zmuszają” system do wysłania do ofiary wiadomości z domeny firmy.

W skrócie

  • Fala miała być widoczna od 18 stycznia 2026; opisywano setki maili o dziwnych, czasem alarmujących tematach.
  • Mechanizm opiera się na anonimowym tworzeniu ticketów + autoresponderach/triggerach wysyłających potwierdzenia.
  • Ponieważ maile wychodzą z legalnych domen firm, potrafią omijać filtry antyspamowe skuteczniej niż klasyczny spam.
  • Zendesk podkreśla, że to zwykle efekt konfiguracji, a nie „klasyczna luka”/CVE, i rekomenduje zmiany ustawień (m.in. ograniczenie kto może tworzyć tickety, zmiany w triggerach pierwszej odpowiedzi).

Kontekst / historia / powiązania

To nie pierwszy raz, gdy nadużycia wokół Zendesk przybierają formę „email bombingu”. W październiku 2025 r. opisywano przypadki zalewania skrzynek tysiącami powiadomień „ticket creation notification”, wysyłanych z wielu firm jednocześnie — i co ważne: wiadomości wyglądały na pochodzące od marek, a nie bezpośrednio od Zendesk.

Równolegle, pod koniec 2025 r. ReliaQuest opisywał kampanie ukierunkowane na ekosystem Zendesk: infrastruktura phishingowa (typosquatting domen) oraz próby „ticket injection” ukierunkowane na pracowników helpdesku. To inny wektor niż relay spam, ale pokazuje, że platformy wsparcia stały się pełnoprawnym elementem powierzchni ataku.

Analiza techniczna / szczegóły luki

1) Jak działa „przejęcie” systemów ticketowych bez włamania?

W wielu wdrożeniach Zendesk dopuszcza się scenariusz: „klient bez konta → formularz zgłoszenia → automatyczne potwierdzenie e-mail”. Atakujący wykorzystuje to w bardzo prosty sposób:

  1. Składa zgłoszenie (ticket) jako „requester” podając adres ofiary.
  2. System (autoresponder/trigger) wysyła do ofiary potwierdzenie przyjęcia zgłoszenia.
  3. Atak jest skalowany przez iterowanie po listach adresów — stąd efekt masowej fali.

2) Dlaczego te wiadomości tak dobrze „przechodzą”?

Wiadomości wychodzą z infrastruktury i domen firm, które realnie używają Zendesk. To powoduje, że:

  • wyglądają wiarygodnie (brand + prawidłowy nadawca),
  • częściej przechodzą przez filtry, bo nie są wysyłane z typowych „spamowych” domen,
  • potrafią budzić niepokój (dziwne tematy, pseudo-prawne groźby, „law enforcement” itp.).

3) Charakter wiadomości w styczniu 2026

BleepingComputer wskazywał, że w tej fali tematy były często absurdalne/chaotyczne (czasem z Unicode „ozdobnikami”), a sama treść nie zawsze zawierała typowe linki phishingowe — co może sugerować trolling lub testowanie przepustowości filtrów i reakcji organizacji.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko reputacyjne dla firm: odbiorcy widzą spam „od Waszego supportu”, mimo że zespół nic nie wysyłał.
  2. Ryzyko phishingu 2. fazy: nawet jeśli w aktualnej fali linków bywa mało, mechanizm świetnie nadaje się do kampanii z linkiem/załącznikiem — bo mail startuje z wiarygodnego kanału. (To wniosek praktyczny z opisanego mechanizmu i historii podobnych nadużyć).
  3. Denial of Inbox / przeciążenie: ofiary dostają setki maili, a zespoły wsparcia/IT muszą obsłużyć zgłoszenia, skargi i filtrowanie.
  4. Chaos operacyjny: w części organizacji realne tickety mogą ginąć w szumie, jeśli atak równolegle generuje śmieciowe zgłoszenia w systemie.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji korzystających z Zendesk

  • Ogranicz tworzenie zgłoszeń do zweryfikowanych / dodanych użytkowników (jeśli to możliwe w Waszym procesie). Zendesk wprost wskazuje „permit only added users to submit tickets” jako środek ograniczający relay spam.
  • Przejrzyj triggery „pierwszej odpowiedzi” i autorespondery: jeśli wysyłają treść/tytuł/placeholdery oparte o dane z ticketa, to atakujący może je „wstrzyknąć” do wiadomości wychodzącej. Zendesk rekomenduje m.in. usuwanie wybranych placeholderów z first-reply triggers.
  • Włącz dodatkowe mechanizmy anty-automatyzacyjne (tam gdzie dostępne): rate limiting, CAPTCHA/wyzwania, monitorowanie anomalii wolumetrycznych. Zendesk deklaruje też wdrażanie „new safety features”, w tym monitoring i limity szybciej wyłapujące nietypową aktywność.
  • Telemetry & alerting: ustaw alerty na nietypowe wzrosty ticketów / powiadomień e-mail, koreluj z logami bramki pocztowej (SEG) i SIEM.
  • Przygotuj gotową komunikację dla klientów (template): „to nie był Wasz ticket”, „nie klikaj”, „jak rozpoznać prawdziwe odpowiedzi”, gdzie zgłaszać incydent.

Dla odbiorców (osób, które dostały takie maile)

  • Ignoruj/usuń podejrzane powiadomienia i nie klikaj linków, jeśli wyglądają nietypowo — to wprost rekomenduje Zendesk.
  • Jeśli fala jest uciążliwa: reguły filtrujące po temacie/nadawcy + zgłoszenie do dostawcy poczty jako spam (żeby trenować filtry).
  • Gdy mail wygląda na prawdziwy incydent w koncie (np. „reset hasła”): wchodź do serwisu ręcznie (bookmark / wpisanie adresu), nie przez link z wiadomości.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Styczeń 2026 (relay spam/ticket-notification abuse): nacisk na skalę i „chaos” tematów, często bez klasycznych linków phishingowych — bardziej masowa „fala spamu” wykorzystująca legalne powiadomienia.
  • Październik 2025 (email bombing opisywany przez Krebsa): podobny rdzeń (anonimowe tickety + powiadomienia), ale mocniej akcentowany był efekt „many-against-one” (wysyłka z wielu marek naraz) oraz fakt, że reply-to i nadawca są domenami klientów.
  • Kampanie phishingowe wokół Zendesk (ReliaQuest, XI–XII 2025): zamiast nadużywać triggerów do wysyłki, atakujący budują fałszywe domeny/SSO i próbują przejąć dostęp (credential harvesting), czasem też „wstrzykując” złośliwe treści do zgłoszeń kierowanych do helpdesku. To inna klasa zagrożeń, ale ta sama „powierzchnia ataku”: procesy wsparcia i narzędzia SaaS.

Podsumowanie / kluczowe wnioski

Fala spamu wykorzystująca Zendesk nie musi oznaczać „włamania” do firmy — często wystarczy otwarta konfiguracja (anonimowe zgłoszenia) plus automatyczne powiadomienia e-mail. To jednak wciąż realne ryzyko: reputacyjne, operacyjne i (potencjalnie) phishingowe, bo kanał jest wiarygodny i trudniejszy do filtrowania. Najskuteczniejsze podejście to ograniczenie anonimowości, przegląd triggerów/autoresponderów oraz twardsze mechanizmy anty-automatyzacyjne i monitoring wolumetrii.

Źródła / bibliografia

  1. BleepingComputer – opis fali od 18 stycznia 2026 i mechanizmu nadużycia potwierdzeń ticketów. (BleepingComputer)
  2. Zendesk (oficjalny komunikat) – „Important notice about recent spam emails via Zendesk”, definicja relay spamu i rekomendowane ustawienia. (support.zendesk.com)
  3. Dark Reading – kontekst „relay spam”, komentarz Zendesk o nowych zabezpieczeniach/limitach i wzmianka o incydentach u klientów. (Dark Reading)
  4. KrebsOnSecurity – „Email Bombs Exploit Lax Authentication in Zendesk” (październik 2025), szczegóły mechaniki i efektu „z domen klientów”. (krebsonsecurity.com)
  5. ReliaQuest – analiza kampanii wymierzonych w środowiska Zendesk (typosquatting/SSO/ticket injection) – kontekst porównawczy. (ReliaQuest)