NovaCookies wykorzystuje prawdziwe powiadomienia Docusign do phishingu Microsoft 365

NovaCookies: co Island opisał 26 sierpnia 2026

26 sierpnia 2026 roku firma Island opublikowała analizę usługi phishingowej NovaCookies. Badacze opisują ją jako komercyjny zestaw typu adversary-in-the-middle (AiTM), przygotowany do przejmowania uwierzytelnionych sesji Microsoft 365.

Najciekawszy element tej analizy nie zaczyna się jednak na fałszywej stronie logowania. W jednym z obserwowanych łańcuchów pierwszym etapem było prawdziwe powiadomienie Docusign i prawdziwa koperta otwierana w legalnym serwisie. Złośliwy był dokument umieszczony wewnątrz.

To zmienia prostą regułę „sprawdź nadawcę”. Wiadomość może przejść techniczne kontrole nadawcy i pochodzić z prawdziwej platformy, a mimo to dalsze działanie zaproponowane w dokumencie może prowadzić do phishingu.

Island podaje też, że NovaCookies była reklamowana za 320 USD miesięcznie lub 200 USD za 14 dni. Te kwoty trzeba czytać precyzyjnie: pochodzą z materiałów konta promującego usługę. Badacze nie znaleźli niezależnego dowodu konkretnego zakupu, płatności ani tożsamości sprzedawcy.

Prawdziwy Docusign, fałszywy dokument w środku

Island określa ten wariant jako „envelope inside an envelope”. Odbiorca dostaje prawdziwe powiadomienie Docusign, przechodzi do prawdziwego widoku dokumentu, a dopiero treść wewnątrz próbuje skierować go dalej.

W opisanym przypadku fałszywy dokument udawał informację o pliku dotyczącym rozliczenia i zachęcał do jego otwarcia. Z punktu widzenia ochrony poczty istotne jest miejsce, w którym znajduje się odnośnik: nie musi być obecny bezpośrednio w pierwotnym e-mailu. Może pojawić się dopiero w dokumencie otwartym w zaufanej usłudze.

Docusign niezależnie ostrzega przed takim sposobem nadużywania swojej platformy. W alercie z 20 sierpnia 2026 roku firma opisała inną kampanię, w której zarejestrowane konta wysyłały prawdziwe koperty z dokumentem prowadzącym do złośliwej strony. To nie jest dowód, że oba przypadki prowadzi ta sama grupa. Potwierdza natomiast problem, który ma znaczenie dla użytkownika: autentyczność powiadomienia i platformy nie jest tym samym co autentyczność treści dokumentu.

Podobny szerszy problem opisujemy w materiale 67% phishingu przechodzi DMARC. Zaufanie pod presją. Kontrole nadawcy nadal są potrzebne, ale nie wydają werdyktu o intencji każdej wiadomości i każdego procesu uruchomionego później.

Legalne przekierowanie może być tylko etapem drogi

W części obserwowanych łańcuchów po kliknięciu odbiorca nie trafiał od razu z Docusign do finalnej strony. Island opisuje użycie legalnych adresów Microsoft, a rzadziej Google, jako pośrednich punktów przekierowania.

Microsoft szczegółowo opisał ten mechanizm już 2 marca 2026 roku w analizie OAuth redirection abuse. Atakujący rejestruje aplikację we własnym środowisku i wskazuje kontrolowany przez siebie adres przekierowania. Odpowiednio przygotowane żądanie może doprowadzić do błędu w procesie OAuth, po którym przeglądarka przechodzi do wcześniej zarejestrowanego adresu.

Ten etap łatwo opisać zbyt mocno, dlatego warto zaznaczyć dwie rzeczy. Po pierwsze, sam błąd OAuth nie wydaje napastnikowi tokenu. Po drugie, w tym miejscu użytkownik nie zatwierdza dostępu aplikacji w klasycznym ekranie zgody OAuth. Znaczenie tej techniki polega na czym innym: podróż zaczyna się na domenie znanego dostawcy tożsamości, a dopiero później przeglądarka trafia do infrastruktury atakującego.

Każdy etap może więc wyglądać osobno wiarygodnie: Docusign, następnie adres Microsoft, później ekran podobny do logowania Microsoft 365. Bezpiecznej decyzji nie można opierać wyłącznie na tym, że jeden z wcześniejszych adresów był prawdziwy.

Co NovaCookies robi podczas logowania Microsoft 365

Końcowym elementem jest relay AiTM. Użytkownik widzi proces logowania Microsoft 365, a infrastruktura NovaCookies pośredniczy w wymianie z prawdziwą usługą. Hasło i kolejne żądania MFA mogą być przekazywane do Microsoft w czasie rzeczywistym. Gdy logowanie zakończy się sukcesem, pośrednik może przechwycić sesję wydaną po uwierzytelnieniu.

Dlatego nie należy pisać, że NovaCookies „łamie MFA”. Użytkownik faktycznie wykonuje logowanie i zatwierdza wymagany drugi składnik, ale robi to przez infrastrukturę kontrolowaną przez napastnika. Celem jest nie tylko hasło, lecz także sesja powstała po prawidłowym uwierzytelnieniu.

Szerzej ten mechanizm wyjaśniamy w artykule Phishing omijający MFA AiTM. W przypadku NovaCookies istotny jest przede wszystkim sposób, w jaki użytkownik zostaje doprowadzony do pośrednika przez kolejne elementy wzbudzające zaufanie.

Island oraz Microsoft wskazują na uwierzytelnianie odporne na phishing, w tym passkeys i klucze FIDO2, jako ochronę, która zmienia ten model ataku. Takie metody są związane z właściwym pochodzeniem strony i nie powinny poprawnie uwierzytelnić użytkownika do witryny pośrednika podszywającej się pod docelową usługę.

Czego badanie NovaCookies nie potwierdza

W świeżych alertach szczególnie łatwo pomylić widoczną infrastrukturę z potwierdzonym skutkiem. Island sam wyznacza granice swoich danych.

Z analizy wynika, że:

• w artefaktach kampanii pojawiały się setki organizacji z wielu regionów i sektorów;
• prawie 90% organizacji w analizowanym zbiorze było związanych z dużą falą przynęt na domenach .vu;
• publiczny pakiet wskaźników zawiera 755 domen ocenionych jako dedykowana złośliwa infrastruktura;
• nowe elementy infrastruktury były nadal obserwowane w sierpniu 2026 roku.

Nie wynika z tego, że setki organizacji zostały przejęte. Island zaznacza, że obecność organizacji w artefaktach wskazuje na celowanie, a nie na kliknięcie, podanie danych lub skuteczne przejęcie sesji. Potwierdzenie kompromitacji wymaga osobnego materiału dowodowego.

Nie ma też podstaw, aby na bazie sprawdzonych źródeł przedstawiać NovaCookies jako aktywną kampanię wymierzoną w Polskę. Dane Island pokazują szeroki zasięg geograficzny, ale Polska nie została wskazana jako potwierdzony obszar obserwowanej aktywności.

Jak sprawdzić niespodziewaną kopertę Docusign

Najbardziej użyteczna zmiana zachowania dotyczy pytania, które zadaje odbiorca. Zamiast „czy ten e-mail naprawdę przyszedł z Docusign?” warto sprawdzić również: czy spodziewam się tego dokumentu, czy rozpoznaję osobę lub proces biznesowy i czy dalsze działanie ma sens.

Docusign zaleca przy niespodziewanych wiadomościach kontakt z nadawcą niezależnym, znanym kanałem. Jeżeli nie masz pewności, czy dokument jest prawdziwy, nie trzeba korzystać z odnośnika w wiadomości. Można wejść samodzielnie na oficjalną stronę Docusign i użyć funkcji dostępu do dokumentów wraz z kodem bezpieczeństwa podanym w powiadomieniu.

W praktyce warto przerwać proces, gdy dokument:

• pojawia się bez oczekiwanego kontekstu biznesowego;
• po otwarciu przenosi użytkownika do kolejnej usługi i wymaga logowania, którego nie było w spodziewanym procesie;
• kieruje z legalnej platformy na nieznaną domenę;
• wykorzystuje rozliczenie, fakturę lub pilny dokument jako uzasadnienie dla dodatkowego logowania;
• prowadzi przez kilka wiarygodnie wyglądających etapów, ale nie da się potwierdzić samej prośby u nadawcy.

Nie ma jednej domeny, której zapamiętanie rozwiąże problem. NovaCookies obraca infrastrukturą, a legalne strony mogą być wykorzystywane jako element pośredni. Dla pracownika bardziej odporna jest reguła procesowa: niespodziewany dokument wymagający logowania potwierdzam poza ścieżką, którą dostałem w wiadomości.

Co zrobić po wpisaniu hasła lub potwierdzeniu MFA

Jeżeli użytkownik tylko otrzymał podejrzaną kopertę i nie wykonał działania, powinien ją zgłosić zgodnie z procedurą organizacji. Docusign udostępnia również mechanizm Report Abuse dla podejrzanych dokumentów.

Jeżeli użytkownik przeszedł dalej i wpisał dane logowania albo zatwierdził MFA, zdarzenie należy potraktować jako możliwe przejęcie sesji, a nie wyłącznie wyciek hasła. Island zaleca wtedy między innymi:

1. unieważnienie aktywnych sesji;
2. zmianę danych logowania;
3. sprawdzenie logowań w systemie tożsamości;
4. przegląd nowych lub zmienionych metod MFA;
5. kontrolę zgód OAuth;
6. sprawdzenie przekierowań i reguł skrzynki pocztowej.

Sama zmiana hasła może być niewystarczająca, jeżeli napastnik ma jeszcze aktywną sesję. To właśnie różni reakcję na AiTM od prostego przypadku, w którym ktoś poznał wyłącznie hasło.

Co ten przypadek zmienia w security awareness

NovaCookies dobrze pokazuje problem z ćwiczeniami opartymi wyłącznie na oczywistych błędach w wiadomości. W tym scenariuszu początek może być technicznie poprawny: prawdziwa platforma dokumentowa i prawdziwe powiadomienie. Dopiero później użytkownik jest przenoszony poza oczekiwany proces.

Dlatego pracownicy powinni ćwiczyć nie tylko wyszukiwanie literówek i podejrzanych domen, lecz także weryfikowanie sensu całego procesu biznesowego. Czy dokument był oczekiwany? Czy nadawca rzeczywiście miał go wysłać? Dlaczego dokument wymaga ponownego logowania? Czy można potwierdzić prośbę przez Teams, telefon lub znany kontakt, zamiast kontynuować z otrzymanego odnośnika?

Pokrewny scenariusz z dokumentami opisujemy w materiale Fałszywe powiadomienie SharePoint i przejęcie konta Microsoft 365. NovaCookies dodaje do tego jeden szczególnie użyteczny przypadek szkoleniowy: pierwszy element łańcucha może być prawdziwy, a decyzja nadal może być niebezpieczna.

W testach phishingowych dla firm warto uwzględniać także takie sytuacje: legalna platforma, dokument zgodny z codzienną pracą i dopiero kolejny krok, który powinien skłonić odbiorcę do zatrzymania procesu i niezależnej weryfikacji.