Ponad milion maili BEC: fałszywi prezesi, faktury i ślady AI

Wiadomości podszywały się pod osoby z kierownictwa i przedstawiały fałszywe faktury jako część wcześniej uzgodnionego procesu. Dodatkowy, spreparowany kontekst korespondencji miał wzmacniać wrażenie, że płatność została już omówiona.

Microsoft zauważył także oznaki zgodne z użyciem generatywnej AI przy budowie szablonów. Źródło nie potwierdza jednak, że cała treść kampanii została wygenerowana przez AI ani nie określa dokładnego udziału modelu w jej przygotowaniu.

Dla organizacji najważniejszy jest proces decyzyjny. Profesjonalny język, znajoma nazwa i dobrze wyglądający dokument nie powinny zastępować niezależnego potwierdzenia nietypowej płatności.

Co dokładnie wykrył Microsoft

Microsoft Security Research, zespół badawczy Microsoftu zajmujący się analizą zagrożeń, opisał kampanię wykrytą między 3 a 5 sierpnia 2026. Według publikacji wysłano wtedy ponad milion wiadomości.

Skala była duża, ale geograficznie nierówna. Microsoft podaje, że 87,7% wiadomości trafiło do użytkowników w Stanach Zjednoczonych. Tych danych nie należy więc przedstawiać jako pomiaru typowej skali BEC w Polsce czy Europie.

Odbiorcami były między innymi osoby odpowiedzialne za zobowiązania i płatności. Wiadomości sugerowały, że polecenie pochodzi od osoby z kierownictwa firmy i że przedstawiona faktura została wcześniej zaakceptowana.

Microsoft opisał także fałszywą fakturę odnoszącą się do usługi przedstawianej jako subskrypcja ServiceNow oraz spreparowany fragment wcześniejszej korespondencji. Jednocześnie badacze nie znaleźli dowodów, że ServiceNow lub inne legalne organizacje wykorzystane w tej historii zostały przejęte.

Jak zbudowano pozory wiarygodności

W tym przypadku istotne było połączenie kilku sygnałów zaufania. Sama wiadomość nie była jedynym elementem, który odbiorca miał ocenić. Towarzyszył jej dokument wyglądający jak normalna faktura oraz kontekst sugerujący wcześniejsze uzgodnienia.

Z perspektywy pracownika taki układ może przypominać rutynowy etap pracy: decyzja miała już zapaść, a do wykonania pozostała tylko płatność. Właśnie dlatego procedura finansowa powinna być ważniejsza niż wygląd wiadomości.

To odróżnia ten przypadek od prostego oszustwa opartego wyłącznie na pilnym poleceniu. Pozorna wiarygodność była budowana na kontekście biznesowym, a nie na jednym technicznym sygnale.

Podobny problem z zaufaniem do historii biznesowej opisywaliśmy w materiale Phantom Deal: fałszywe M&A, NDA i WhatsApp w BEC. Tam scenariusz dotyczył poufnej transakcji i zmiany kanału komunikacji. Kampania Microsoftu jest odrębnym, datowanym przypadkiem związanym z fakturą i płatnością.

Gdzie pojawia się AI

Microsoft formułuje wniosek o generatywnej AI ostrożnie. Badacze wskazują cechy szablonów, które są zgodne z użyciem narzędzi generatywnych podczas ich przygotowania.

To nie jest dowód pozwalający stwierdzić, że „AI napisała milion maili”. Microsoft zaznacza, że obserwowane oznaki nie ustalają samodzielnie zakresu generowania treści przez AI.

Ta granica ma znaczenie, bo łatwo pomylić dwie różne informacje. Potwierdzona jest skala kampanii i jej mechanizm. Użycie AI jest opisane jako wsparcie procesu przygotowania szablonów na podstawie zaobserwowanych cech, bez dokładnego określenia udziału automatyzacji.

Z punktu widzenia security awareness praktyczny wniosek jest bardziej przyziemny: poprawny język i profesjonalne formatowanie nie są wystarczającym kryterium zaufania. Kontrola powinna opierać się na tym, czy żądanie odpowiada rzeczywistemu procesowi organizacji.

Dlaczego kontrola płatności jest kluczowa

BEC nie musi kończyć się na kradzieży hasła. W wielu scenariuszach celem jest decyzja biznesowa: wykonanie płatności, zmiana danych beneficjenta lub zaakceptowanie nietypowego polecenia.

Artykuł Zatrzymania po oszustwach BEC pozostaje szerszym materiałem o tym mechanizmie i zasadach ochrony płatności. Nowy przypadek Microsoftu pokazuje natomiast, jak duża kampania może próbować wtopić fałszywe żądanie w zwykły obieg dokumentów.

Organizacja powinna z góry ustalić sytuacje, które zatrzymują płatność do czasu dodatkowego sprawdzenia. Przykładem jest nieoczekiwana faktura, nietypowa prośba osoby z kierownictwa, zmiana danych płatności albo presja na pominięcie standardowej ścieżki akceptacji.

Taka reguła działa nawet wtedy, gdy wiadomość nie zawiera oczywistych błędów. Jest oparta na procesie, a nie na jakości przynęty.

Jak weryfikować nietypowe żądanie

FBI w materiale o Business Email Compromise zaleca potwierdzanie żądań płatności i zakupów bezpośrednio z osobą, która miała je zlecić. Zmiany danych rachunku lub sposobu płatności również powinny być sprawdzane niezależnie.

W praktyce oznacza to użycie wcześniej znanego numeru, katalogu firmowego lub zatwierdzonego kanału komunikacji zamiast danych podanych wyłącznie w wiadomości. Warto potwierdzić nie tylko samą zgodę na płatność, lecz także beneficjenta, rachunek, kwotę i podstawę biznesową.

IC3 również wskazuje drugi kanał jako sposób weryfikacji zmian danych rachunku. Przy większych lub nietypowych płatnościach dodatkową ochroną jest druga akceptacja.

Jeżeli potwierdzenie nie jest możliwe, bezpieczniejszą decyzją jest wstrzymanie przelewu niż traktowanie braku odpowiedzi jako zgody.

Co powinny zrobić IT i zespół bezpieczeństwa

Proces finansowy jest jedną warstwą ochrony. Druga dotyczy poczty i tożsamości.

Microsoft zaleca między innymi ochronę przed podszywaniem się, właściwą konfigurację mechanizmów antyphishingowych oraz możliwość reagowania na wiadomości uznane za złośliwe już po dostarczeniu.

Po zgłoszeniu podejrzanej wiadomości organizacja powinna móc szybko sprawdzić jej zasięg, ustalić, czy podobna treść trafiła do innych osób, oraz ocenić, czy doszło do odpowiedzi, zmiany danych dostawcy albo uruchomienia płatności.

W takich przypadkach zespół bezpieczeństwa i osoby odpowiedzialne za finanse powinny działać wspólnie. Samo usunięcie wiadomości ze skrzynki nie zamyka sprawy, jeżeli proces finansowy został już uruchomiony.

Jak wykorzystać przypadek w security awareness

Ten przypadek dobrze pokazuje, dlaczego szkolenie nie powinno ograniczać się do szukania literówek i podejrzanych linków. Pracownik powinien rozpoznawać odstępstwo od procesu i wiedzieć, kiedy zatrzymać działanie.

W testach phishingowych dla firm warto mierzyć nie tylko kliknięcia, ale też zgłoszenie wiadomości, czas reakcji i próbę niezależnej weryfikacji krytycznej prośby. Ćwiczenie nie musi używać prawdziwych danych dostawców ani realnych rachunków.

Dla organizacji finansowych i zespołów obsługujących płatności taki scenariusz warto połączyć z zasadą dwóch osób oraz niezależnym potwierdzeniem danych beneficjenta. Więcej kontekstu znajduje się na stronie Finanse i bankowość.

Raport APWG za Q2 2026 pokazuje szerszy kontekst BEC z żądaniem przelewu, ale dotyczy innego zbioru danych. W materiale APWG Q2 2026: smishing +40%, BEC +88% i wzrost phishingu wyjaśniamy, dlaczego tych statystyk nie należy mieszać z liczbą wiadomości z pojedynczej kampanii Microsoftu.

Czego ten przypadek nie dowodzi

Źródło Microsoftu nie pozwala stwierdzić, że:

• ponad milion firm padło ofiarą oszustwa;
• ponad milion płatności zostało wykonanych;
• kampania miała podobną skalę w Polsce;
• ServiceNow zostało przejęte;
• każda wiadomość została w całości wygenerowana przez AI;
• cechy kojarzone z AI są wystarczającą metodą wykrywania BEC.

Potwierdzona jest skala wysyłki obserwowana przez Microsoft, użycie podszywania się, fałszywych dokumentów i spreparowanego kontekstu oraz oznaki zgodne z pomocą generatywnej AI przy tworzeniu szablonów.

Wniosek

Ponad milion wiadomości w jednej kampanii pokazuje, że BEC może łączyć skalę masowej wysyłki z historią wyglądającą na dopasowaną do konkretnej firmy. Profesjonalna faktura i pozorna wcześniejsza akceptacja nie powinny jednak zastępować weryfikacji.

Najważniejsza kontrola pozostaje procesowa: zatrzymać nietypową płatność, potwierdzić ją znanym kanałem i nie pozwolić, aby e-mail sam sobie był dowodem autentyczności.