Email bombing i fałszywy helpdesk w Teams. Gdy atak zaczyna się od przeciążenia użytkownika

2026-05-04

TL;DR

Atakujący coraz częściej łączą email bombing, czyli celowe zalewanie skrzynki dużą liczbą wiadomości, z podszyciem się pod helpdesk w Microsoft Teams. Najpierw tworzą problem: użytkownik widzi dziesiątki albo setki wiadomości, powiadomień i zapisów do przypadkowych usług. Potem pojawia się rzekomy pracownik IT, który oferuje pomoc.

W praktyce ta pomoc może oznaczać nakłonienie użytkownika do uruchomienia Quick Assist, czyli wbudowanego w Windows narzędzia pomocy zdalnej, instalacji AnyDesk, ConnectWise albo innego narzędzia RMM. RMM to oprogramowanie używane legalnie przez działy IT do zdalnego monitorowania i zarządzania komputerami. W rękach atakującego staje się wygodną drogą do przejęcia urządzenia.

To nie jest klasyczny phishing z jednym linkiem. To scenariusz, w którym napastnik najpierw wywołuje chaos, a potem sam wchodzi w rolę rozwiązania problemu.

O co chodzi w tym scenariuszu

Według eSentire, od początku 2026 roku rośnie liczba kampanii phishingowych opartych na Microsoft Teams. Atakujący podszywają się pod IT Support, Helpdesk albo zespoły bezpieczeństwa i próbują przekonać pracowników do oddania zdalnego dostępu do urządzenia.

Schemat jest prosty, ale dobrze dopasowany do realnej pracy w firmie. Najpierw ofiara doświadcza email bombingu. Skrzynka zaczyna być zalewana wiadomościami, potwierdzeniami rejestracji, spamem, powiadomieniami albo niechcianymi subskrypcjami. Użytkownik widzi realny problem i chce go szybko zatrzymać.

Następnie pojawia się wiadomość w Teams. Nadawca wygląda jak osoba z IT, Security Help Desk albo Windows Support. Pisze, że zauważył problem ze skrzynką i może pomóc. W tym momencie atakujący nie musi już przekonywać ofiary, że awaria istnieje. Ofiara już ją widzi.

I właśnie dlatego ten model jest groźny. Socjotechnika nie zaczyna się od obietnicy. Zaczyna się od prawdziwego dyskomfortu, który napastnik sam wcześniej wywołał.

Teams nie jest problemem. Problemem jest zaufanie do kanału

W tym scenariuszu Microsoft Teams nie jest złośliwym narzędziem. Jest normalnym narzędziem pracy, które atakujący nadużywają jako zaufanego kanału kontaktu.

Microsoft opisywał już wcześniej, że Teams może być wykorzystywany przez cyberprzestępców i aktorów państwowych na różnych etapach łańcucha ataku: przez czat, połączenia, spotkania i udostępnianie ekranu. W nowszym opisie scenariuszy cross-tenant helpdesk impersonation Microsoft pokazał także, jak atakujący wykorzystują zewnętrzne tenanty Teams do podszywania się pod wsparcie techniczne i prowadzenia użytkownika w stronę zdalnego dostępu oraz kradzieży danych.

Tenant w Microsoft 365 oznacza oddzielną przestrzeń organizacji w chmurze Microsoftu. Firma ma własny tenant, partner może mieć własny, a atakujący może stworzyć nowy tenant z nazwą sugerującą dział IT, helpdesk albo security. Dla użytkownika wiadomość z Teams może wyglądać mniej podejrzanie niż zwykły e-mail, szczególnie jeśli przychodzi dokładnie wtedy, gdy w skrzynce dzieje się coś dziwnego.

To jest sedno problemu. Napastnik nie musi łamać Teams. Wystarczy, że użyje go w sposób, który wygląda jak normalne wsparcie techniczne.

Jak wygląda łańcuch ataku

Najczęściej łańcuch zaczyna się od zalania skrzynki wiadomościami. To tworzy presję, chaos i poczucie, że coś jest nie tak z kontem. Potem przychodzi kontakt w Teams od rzekomego helpdesku. Osoba po drugiej stronie mówi, że pomoże zatrzymać spam, naprawić filtr poczty albo zainstalować lokalną poprawkę.

W analizie Google Threat Intelligence Group dotyczącej UNC6692 atakujący najpierw przeprowadzili dużą kampanię e-mailową, która miała przytłoczyć ofiarę wiadomościami. Następnie skontaktowali się przez Microsoft Teams, podszywając się pod helpdesk i oferując pomoc przy problemie z pocztą.

Ofiara była nakłaniana do kliknięcia linku i instalacji rzekomej lokalnej poprawki. Poprawka miała chronić konto przed email bombingiem, ale w rzeczywistości uruchamiała kolejne etapy ataku. W łańcuchu pojawiało się między innymi AutoHotKey, czyli legalne narzędzie do automatyzacji działań w Windows. Administratorzy i zaawansowani użytkownicy mogą używać go do skrótów i makr, ale w tym przypadku posłużyło do wykonania złośliwych kroków.

Google opisał też komponenty z rodziny SNOW, w tym złośliwe rozszerzenie Chromium określane jako SNOWBELT. Chromium to silnik, na którym opierają się między innymi Chrome i Edge. Złośliwe rozszerzenie przeglądarki może przechwytywać dane, obserwować aktywność użytkownika albo wspierać dalsze działania napastnika.

To bardzo ważny detal. Atak nie kończył się na rozmowie. Rozmowa była tylko sposobem, żeby użytkownik sam uruchomił kolejny etap.

Zdalny dostęp jako nowy załącznik

W starszym modelu phishingu użytkownik miał otworzyć załącznik albo podać hasło. W tym modelu ma zrobić coś groźniejszego: oddać komuś ekran, klawiaturę i sesję.

eSentire opisuje przypadki, w których po uzyskaniu dostępu atakujący pobierali przenośne wersje WinSCP i wykorzystywali je do wyprowadzania danych z przejętych hostów. WinSCP to legalne narzędzie do przesyłania plików, często używane przez administratorów. W legalnym scenariuszu pomaga przenieść dane między systemami. W ataku może stać się prostą drogą do eksfiltracji, czyli wyniesienia plików poza organizację.

W innych wariantach pojawiały się Quick Assist, AnyDesk, ConnectWise albo inne narzędzia zdalnego dostępu. Po przejęciu interaktywnej kontroli nad urządzeniem atakujący może pobrać kolejne payloady, utrzymać dostęp, przygotować środowisko pod ransomware albo od razu szukać danych do kradzieży.

To pokazuje, że narzędzia zdalnego wsparcia stały się dla phishingu tym, czym kiedyś były złośliwe załączniki. Są legalne, powszechnie znane i używane przez IT. Właśnie dlatego mogą zostać nadużyte.

Ten wątek dobrze łączy się z materiałem BlackFile pokazuje nowy model wymuszeń. Najpierw helpdesk, potem konto kierownictwa, na końcu dane, gdzie punktem wejścia również był proces zaufania do helpdesku, a nie klasyczny malware.

Dlaczego email bombing tak dobrze przygotowuje ofiarę

Email bombing jest w tym scenariuszu czymś więcej niż hałasem. To element psychologicznego przygotowania. Użytkownik widzi realny problem, a jego naturalną reakcją jest chęć szybkiego odzyskania kontroli nad skrzynką. Gdy chwilę później pojawia się rzekomy helpdesk, komunikat brzmi wiarygodnie.

To działa, bo atakujący nie musi wymyślać awarii. On ją najpierw sam wywołuje.

Dodatkowo email bombing odwraca uwagę. W zalanej skrzynce łatwiej przeoczyć prawdziwe alerty bezpieczeństwa, powiadomienia o logowaniu, wiadomości z systemów monitoringu albo potwierdzenia zmian na koncie. Użytkownik i zespół IT widzą dużo szumu, a właściwa akcja dzieje się przez Teams lub zdalny dostęp.

To dlatego taki przypadek powinien być traktowany jako pełny incydent socjotechniczny, a nie jako zwykły problem ze spamem.

Zewnętrzny kontakt w Teams musi przestać wyglądać neutralnie

Jednym z najważniejszych elementów obrony jest kontrola kontaktów z zewnętrznych organizacji w Microsoft Teams. eSentire rekomenduje ograniczanie wiadomości i połączeń z zewnętrznych tenantów, chyba że są rzeczywiście potrzebne biznesowo. Jeśli takie kontakty są wymagane, warto dopuścić je tylko dla zaufanych partnerów i zadbać o wyraźne oznaczenia zewnętrznych nadawców.

To ma duże znaczenie, bo atakujący często tworzą nowe tenanty .onmicrosoft.com z nazwami sugerującymi IT, bezpieczeństwo albo helpdesk. eSentire wskazuje też na domeny jednorazowe, w tym .top, oraz persony o realistycznie brzmiących imionach i nazwiskach połączonych z brandingiem IT.

Dla użytkownika to może wyglądać wiarygodnie. Dla organizacji powinno być sygnałem: ktoś spoza firmy próbuje wejść w rolę wewnętrznego wsparcia.

Dlaczego osoby wysokiego ryzyka są szczególnie narażone

Ten scenariusz jest groźny dla wszystkich użytkowników, ale szczególnie dla osób, które mają większe uprawnienia, dostęp do danych albo silniejszą pozycję w organizacji.

ReliaQuest opisał kampanie łączące email bombing i Teams-based help desk impersonation, kierowane w stronę senior-level employees, czyli osób na wyższych stanowiskach. Według ich obserwacji w marcu 2026 większość analizowanych incydentów tego typu dotyczyła właśnie osób z kadry kierowniczej.

To ma sens. Przejęcie urządzenia osoby z zarządu, finansów, prawnego, HR albo IT daje większą wartość niż przejęcie zwykłej stacji. Może oznaczać dostęp do dokumentów, korespondencji, danych pracowników, systemów SaaS albo dalszych kontaktów w firmie.

Atakujący coraz lepiej rozumieją, że nie trzeba atakować wszystkich. Wystarczy przeciążyć i zmanipulować właściwą osobę.

To nie jest tylko phishing. To operacja na procesie wsparcia

Największy błąd organizacji polegałby na potraktowaniu tego jako kolejnego wariantu phishingu e-mailowego. To jest atak na proces wsparcia IT.

Jeśli firma nie ma jasnych zasad, kto może kontaktować się z użytkownikiem, przez jaki kanał, kiedy wolno uruchomić zdalny dostęp i jak weryfikować tożsamość helpdesku, to zostawia lukę, którą można wykorzystać.

Użytkownik nie powinien musieć zgadywać, czy osoba w Teams jest prawdziwym wsparciem. Powinien mieć prostą zasadę: nie uruchamiam zdalnego dostępu po nieoczekiwanej wiadomości. Nie instaluję poprawek z linku przesłanego na czacie. Nie wykonuję poleceń osoby, której tożsamości nie potwierdziłem przez znany kanał.

To dobrze uzupełnia tekst Warstwa obrony przed phishingiem. Czego brakuje, gdy filtr poczty nie wystarcza. W tym scenariuszu filtr poczty może nawet zauważyć część spamu, ale właściwy atak przenosi się do Teams i narzędzi zdalnego dostępu.

Co powinno zapalić lampkę ostrzegawczą

Najważniejszy sygnał ostrzegawczy to nagłe zalanie skrzynki wiadomościami, a chwilę później kontakt od osoby podającej się za helpdesk. Jeśli ktoś z zewnętrznego konta Teams twierdzi, że pomoże przy problemie z pocztą, trzeba zatrzymać proces.

Podejrzane są również prośby o uruchomienie Quick Assist, AnyDesk, ConnectWise lub innego narzędzia zdalnego dostępu. Tak samo należy traktować prośby o pobranie lokalnej poprawki do poczty, kliknięcie linku z czatu Teams, wykonanie polecenia w PowerShell, CMD albo oknie uruchamiania, wyłączenie zabezpieczeń, podanie kodu MFA lub udostępnienie ekranu osobie, która sama zainicjowała kontakt.

PowerShell i CMD to legalne narzędzia administracyjne w Windows. Same w sobie nie są złośliwe. Problem pojawia się wtedy, gdy nieznana osoba instruuje użytkownika, aby wkleił tam komendę, której nie rozumie.

W normalnym procesie IT użytkownik powinien mieć możliwość zweryfikowania zgłoszenia w systemie ticketowym, przez oficjalny numer helpdesku albo przez znany kanał wewnętrzny.

Co firmy powinny zrobić praktycznie

Po pierwsze, warto ograniczyć komunikację w Teams z zewnętrznymi organizacjami. Jeśli biznes wymaga takiej komunikacji, powinna być zawężona do zaufanych partnerów i jasno oznaczona dla użytkownika.

Po drugie, trzeba kontrolować narzędzia zdalnego dostępu. Quick Assist, AnyDesk, ConnectWise, TeamViewer i podobne narzędzia nie powinny być dostępne bez polityki, monitoringu i jasnej decyzji, kto może ich używać. To samo dotyczy narzędzi do transferu plików, takich jak WinSCP, Rclone, FileZilla czy MegaSync.

Po trzecie, organizacja powinna mieć procedurę potwierdzania nietypowych próśb IT innym kanałem. Jeśli ktoś kontaktuje się przez Teams i prosi o zdalny dostęp, użytkownik powinien przerwać rozmowę i potwierdzić sprawę przez oficjalny numer helpdesku, system ticketowy albo ustalony kanał wewnętrzny.

Po czwarte, trzeba monitorować logi Microsoft 365, wiadomości od zewnętrznych użytkowników Teams, nietypowe uruchomienia narzędzi RMM, podejrzane pobrania z chmury oraz sekwencje typu email bombing → Teams → Quick Assist → PowerShell albo transfer plików.

Po piąte, awareness musi obejmować helpdesk impersonation, czyli podszywanie się pod wsparcie IT. Pracownicy powinni ćwiczyć nie tylko fałszywe maile, ale też sytuacje, w których atakujący najpierw tworzy problem, a potem oferuje pomoc.

Co powinien zapamiętać pracownik

Jeśli skrzynka nagle zostaje zalana wiadomościami, a chwilę później ktoś z Teams oferuje pomoc jako IT, nie należy uruchamiać zdalnego dostępu. Trzeba przerwać rozmowę i samodzielnie skontaktować się z helpdeskiem przez znany kanał.

To jedna z najprostszych zasad, a jednocześnie jedna z najważniejszych. Prawdziwy dział IT może mieć swoje procedury, system zgłoszeń i kanały kontaktu. Nie powinien wymagać, żeby użytkownik pod presją uruchamiał narzędzie zdalnego dostępu po nieoczekiwanej wiadomości od nieznanej osoby.

Jak ten scenariusz ćwiczyć w awareness

Dobry test awareness nie powinien zaczynać się od oczywistego, źle napisanego maila. Powinien odtworzyć logikę ataku.

Najpierw pojawia się chaos w skrzynce albo komunikat o problemie z pocztą. Potem przychodzi wiadomość od rzekomego wsparcia. Na końcu użytkownik musi zdecydować, czy uruchomić zdalny dostęp, kliknąć link albo zgłosić sprawę bezpiecznym kanałem.

Taki scenariusz mierzy coś znacznie ważniejszego niż samą klikalność. Mierzy, czy pracownik rozumie proces. Czy wie, jak wygląda prawdziwy kontakt z IT. Czy umie przerwać rozmowę, gdy ktoś wywiera presję. Czy potrafi zgłosić incydent, zanim udostępni ekran albo urządzenie.

To jest dokładnie ten rodzaj ćwiczeń, którego firmy będą potrzebować coraz częściej, bo ataki coraz rzadziej mieszczą się w jednym kanale.

Gdy pomoc techniczna staje się przynętą

Email bombing połączony z fałszywym helpdeskiem w Microsoft Teams pokazuje ważną zmianę w phishingu. Atakujący nie muszą już tylko wysyłać linku i czekać, aż ktoś kliknie. Mogą najpierw stworzyć problem, potem wejść w zaufany kanał komunikacji i poprowadzić użytkownika krok po kroku do oddania zdalnego dostępu.

To nie jest problem samego Teams. To problem zaufania do narzędzi pracy, niejasnych procedur helpdesku i braku ćwiczeń na scenariusze wielokanałowe.

Jeżeli firma nadal szkoli użytkowników wyłącznie z podejrzanych maili, to nie przygotowuje ich na sytuację, w której atak przychodzi jako pomoc techniczna. A właśnie takie scenariusze coraz częściej decydują o tym, czy incydent zatrzyma się na poziomie irytującego spamu, czy skończy się przejęciem urządzenia, kradzieżą danych albo ransomware.

Jeżeli chcesz sprawdzić, czy Twoi pracownicy rozpoznaliby taki scenariusz, dobrym początkiem jest quiz phishingowy PHISHLY.