Wprowadzenie do problemu / definicja luki
Microsoft i niezależne redakcje branżowe opisują świeżą kampanię phishingową typu Adversary-in-the-Middle (AiTM), która płynnie przechodzi w Business Email Compromise (BEC). najważniejszy wyróżnik: atakujący nie “łamią” SharePoint, tylko nadużywają zaufanego mechanizmu udostępniania plików w SharePoint/OneDrive do dostarczenia przynęty i zwiększenia wiarygodności wiadomości.
AiTM to model, w którym ofiara trafia na stronę pośredniczącą w logowaniu: dane logowania są przekazywane dalej do prawdziwego IdP, a napastnik próbuje przechwycić cookie/sesję. Efekt uboczny jest krytyczny: reset hasła może nie wystarczyć, jeżeli napastnik utrzyma aktywną sesję lub “podkręci” MFA.
W skrócie
- Wejście: e-mail wysłany z przejętego konta zaufanej organizacji (scenariusz “trusted vendor”).
- Przynęta: temat i styl udostępnienia dokumentu + link SharePoint wymagający uwierzytelnienia.
- Po kompromitacji: tworzenie reguł skrzynki (Inbox rules) kasujących przychodzące wiadomości i oznaczających je jako przeczytane.
- Eskalacja: wysyłka ponad 600 kolejnych phishing maili do kontaktów ofiary (wewnętrznych i zewnętrznych).
- Remediacja: poza resetem hasła konieczne bywa unieważnienie sesji/cookies i usunięcie złośliwych reguł skrzynki oraz weryfikacja zmian MFA.
Kontekst / historia / powiązania
To kolejny przykład trendu “living-off-trusted-services”: chmurowe platformy współpracy (SharePoint/OneDrive) są powszechne w organizacjach, więc link do “dokumentu” wygląda normalnie i częściej omija podejścia oparte wyłącznie o reputację domen i analizę treści e-maila.
Ważne jest też odróżnienie tej kampanii od głośnych incydentów z 2025 r. dotyczących eksploatacji luk w SharePoint Server on-prem – tam wektorem były podatności serwera, tu wektorem jest socjotechnika + przejęte tożsamości + nadużycie legalnej usługi.
Analiza techniczna / szczegóły luki
Microsoft opisuje wieloetapowy łańcuch ataku, który warto mapować do TTP:
- Initial Access: “trusted vendor compromise”
Wiadomość startowa przychodzi z konta należącego do zaufanej organizacji (prawdopodobnie wcześniej przejętego). Przynęta udaje standardowy workflow udostępnienia dokumentu w SharePoint. - Click → przekierowania → strona logowania AiTM
Użytkownik klika w link SharePoint, trafia na stronę podszywającą się pod logowanie Microsoft, co ma umożliwić przechwycenie sesji (AiTM). Microsoft zaznacza, iż nie zawsze ma pełną widoczność “za landing page”, ale koreluje późniejsze logowania i wzorce IP. - Post-compromise: reguły skrzynki jako “stealth & persistence”
Po zalogowaniu atakujący tworzy regułę Inbox rule: usuń wszystko przychodzące + oznacz jako przeczytane. To prosta, ale zabójczo skuteczna technika na utrzymanie operacji w ukryciu (ofiara “nie widzi” maili ostrzegawczych, odpowiedzi ofiar phishingu, notyfikacji bezpieczeństwa itd.). - Rozszerzenie zasięgu: phishing z zaufanego, realnego konta
W analizowanym przypadku napastnicy wysłali >600 e-maili do kontaktów ofiary (w tym list dystrybucyjnych), bazując na ostatnich wątkach z jej skrzynki. To pozwala dobrać treść “w kontekst” i zwiększa konwersję. - BEC: aktywne “zarządzanie” skrzynką
Atakujący monitoruje odpowiedzi (np. undelivered i autorespondery), usuwa je, a w razie pytań o autentyczność – potrafi odpisać “potwierdzając”, po czym ślady znikają z mailboxa. - IoC / tropy łowieckie (z raportu Microsoft)
W przykładach “hunting queries” pojawiają się m.in. temat wiadomości “NEW PROPOSAL – NDA” oraz wskazane prefiksy IP używane przy podejrzanych logowaniach (m.in. 178.130.46.* i 193.36.221.*).
Przykładowe zapytania (KQL) inspirowane treścią raportu Microsoft:
// AHQ#1 – Phishing campaign (temat przynęty) EmailEvents | where Subject has "NEW PROPOSAL – NDA" // AHQ#2 – Sign-in activity ze wskazanych prefiksów IP AADSignInEventsBeta | where Timestamp >= ago(7d) | where IPAddress startswith "178.130.46." or IPAddress startswith "193.36.221."Praktyczne konsekwencje / ryzyko
- Kompromitacja tożsamości: AiTM może skutkować przejęciem sesji i obejściem części mechanizmów MFA (zwłaszcza tych podatnych na przejęcie sesji).
- Ciche BEC: reguły skrzynki kasujące/ukrywające pocztę drastycznie obniżają szansę wykrycia i wydłużają “dwell time”.
- Szybka propagacja: phishing z prawdziwego konta pracownika (z historią korespondencji) potrafi przeskoczyć filtry i zarażać kolejne skrzynki w łańcuchu.
- Ryzyko operacyjne dla energetyki: choćby jeżeli kampania startuje od IT/biura, konsekwencje (kradzież danych, fałszywe zlecenia płatnicze, dostęp do systemów powiązanych) są typowe dla BEC i mogą eskalować do zakłóceń procesów.
Rekomendacje operacyjne / co zrobić teraz
- Traktuj to jako incydent tożsamości + poczty, nie tylko “phishing”
- Reset hasła to za mało w AiTM: unieważnij aktywne sesje/cookies i sprawdź, czy nie manipulowano metodami MFA.
- Przejrzyj i usuń podejrzane Inbox rules (delete + mark as read, forward, move to RSS/Archive itd.).
- Wymuś polityki, które utrudniają przejęcie sesji
- Włącz/zaostrz Conditional Access (ryzyko logowania, lokalizacja, stan urządzenia, wymaganie compliant device).
- Rozważ phishing-resistant MFA (np. FIDO2 / CBA) i podejście passwordless tam, gdzie to możliwe.
- Włącz mechanizmy typu Continuous Access Evaluation tam, gdzie środowisko na to pozwala.
- Zabezpieczenia poczty i detekcje
- Uruchom polowania: tematy, nietypowe logowania, tworzenie reguł, masowa wysyłka do list dystrybucyjnych.
- Skonfiguruj alerty na: nowe/zmienione reguły skrzynki, nietypowe forwarding, anomalie MailItemsAccessed, logowania z VPS/anonymizerów. (Microsoft wskazuje gotowe szablony analityczne dla Sentinel/Defender).
- Procesy i higiena współpracy z dostawcami
- Zweryfikuj kanały wymiany dokumentów z partnerami (np. “tylko zatwierdzone tenanty”, podpisy DKIM/DMARC, dodatkowa walidacja przy “pilnych NDA/proposal”).
- Szkol użytkowników: “SharePoint link ≠ gwarancja bezpieczeństwa” – szczególnie gdy e-mail wymusza logowanie lub wygląda “zbyt normalnie”.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- Ta kampania (2026): nadużycie legalnego SharePoint jako elementu socjotechniki + przejęcie tożsamości + AiTM/BEC. Nie wymaga podatności SharePoint.
- Incydenty SharePoint on-prem (2025): wektor oparty o eksploatację luk w SharePoint Server (CISA publikowała ostrzeżenia i guidance), z ryzykiem szerokiego przejęcia serwerów i kluczy/auth.
W praktyce oznacza to, iż choćby organizacje “w pełni załatane” po 2025 r. przez cały czas pozostają podatne na ten scenariusz, bo atak idzie przez ludzi i sesje, a nie przez CVE.
Podsumowanie / najważniejsze wnioski
- Zaufane platformy współpracy są coraz częściej używane jako maskowanie dla phishingu – SharePoint link bywa “konikiem trojańskim” wiarygodności.
- AiTM wymusza zmianę myślenia o remediacji: reset hasła nie kończy incydentu, jeżeli nie zamkniesz sesji i nie posprzątasz skrzynki (reguły!).
- Największe ryzyko w tej kampanii to szybka ekspansja: phishing z realnego konta ofiary + BEC “na autopilocie” poprzez reguły kasowania/ukrywania poczty.
Źródła / bibliografia
- Microsoft Security Blog (Microsoft Defender Security Research Team) – opis łańcucha ataku, mitigacje i hunting queries. (Microsoft)
- SecurityWeek – streszczenie kampanii i najważniejsze elementy BEC (600+ maili, reguły skrzynki). (SecurityWeek)
- Help Net Security – dodatkowe szczegóły operacyjne (temat maila, IP) i rekomendacje remediacyjne. (Help Net Security)
- CISA – kontekst historyczny ostrzeżeń dot. SharePoint (dla porównania “nadużycie usługi” vs “eksploatacja podatności”). (cisa.gov)
