Microsoft Store: przejęty dodatek Outlook „AgreeTo” kradł dane logowania ponad 4 tys. kont. Co to mówi o ryzyku Office Add-ins? - Security Bez Tabu

Microsoft Store: przejęty dodatek Outlook „AgreeTo” kradł dane logowania ponad 4 tys. kont. Co to mówi o ryzyku Office Add-ins?

Wprowadzenie do problemu / definicja luki

Incydent z dodatkiem Outlook „AgreeTo” jest dobrym przykładem ataków łańcucha dostaw (supply chain) w modelu „web app w przeglądarce”, gdzie zaufany kanał dystrybucji (marketplace) dostarcza użytkownikowi treść, która może zmienić się po akceptacji. W tym przypadku napastnik nie musiał łamać kont Microsoft ani infekować endpointów – wystarczyło przejąć kontrolę nad adresem URL, z którego dodatek ładował interfejs.

Efekt: użytkownik otwiera panel dodatku w Outlooku i widzi fałszywe logowanie Microsoft, osadzone w „zaufanym” kontekście aplikacji. Według ustaleń badaczy poszkodowanych miało być ponad 4 tys. kont.

W skrócie

  • „AgreeTo” był legalnym dodatkiem (scheduler spotkań) opublikowanym w Microsoft Office Add-in Store w 2022 r., a następnie porzuconym.
  • Office add-ins w praktyce działają jak adresy URL – Outlook ładuje zdalną zawartość przy każdym uruchomieniu dodatku.
  • Atakujący przejął porzucony adres hostowany na Vercel i podmienił treść na phishing (strona logowania Microsoft), a wykradzione dane eksfiltrował m.in. przez Telegram Bot API.
  • Problem jest „systemowy”: marketplace weryfikuje manifest, ale zawartość pod URL-em może się zmieniać, a uprawnienia dodatku (np. ReadWriteItem) nadal obowiązują.

Kontekst / historia / powiązania

Z relacji badaczy wynika, że „AgreeTo” był realnym produktem, który z czasem przestał być rozwijany. Dodatek pozostał jednak dostępny w sklepie, a jego backend/hosting stał się „osierocony” i możliwy do przejęcia.

To ważne, bo przypomina mechanikę znaną z innych ekosystemów: przejęcia wygasłych domen, opuszczonych projektów, repozytoriów czy paczek – tyle że tutaj dystrybucja odbywała się „wewnątrz Outlooka”, co zwiększa wiarygodność ataku w oczach użytkownika.

Analiza techniczna / szczegóły luki

Jak działają dodatki Outlook/Office (sedno ryzyka)

Microsoft Office Add-ins to aplikacje webowe uruchamiane w ramce (iframe) lub webview. Kluczowe jest to, że manifest dodatku wskazuje, skąd ma być ładowany interfejs i logika – i jest to treść zewnętrzna, pobierana dynamicznie.

W praktyce oznacza to:

  • kontrola bezpieczeństwa w momencie publikacji (manifest) ≠ kontrola tego, co serwer będzie serwował za miesiąc/rok,
  • jeśli ktoś przejmie hosting/domenę wskazaną w manifeście, może podmienić całą „aplikację” użytkownika.

Co zrobił napastnik w kampanii „AgreeToSteal”

Z opisu Koi Security i relacji medialnych łańcuch wyglądał następująco:

  1. Użytkownik uruchamia dodatek „AgreeTo” w Outlooku.
  2. Zamiast funkcji schedulera ładuje się fałszywa strona logowania Microsoft.
  3. Ofiara wpisuje e-mail i hasło.
  4. Dane są wysyłane do atakującego (w raporcie opisano eksfiltrację przez Telegram Bot API) i użytkownik jest przekierowywany na prawdziwą stronę logowania, aby nie wzbudzić podejrzeń.

Uprawnienia: dlaczego „ReadWriteItem” podbija stawkę

Badacze zwracają uwagę, że manifest dodatku deklarował uprawnienia typu ReadWriteItem. W dokumentacji Microsoft jest to poziom pozwalający m.in. na odczyt i modyfikację elementów (np. wiadomości) w kontekście dodatku.

W tym incydencie wykorzystano głównie phishing, ale przy takich uprawnieniach scenariusze eskalacji są oczywiste: odczyt treści maili, „ciche” podbieranie danych, a nawet modyfikowanie elementów (np. dopisywanie treści, tworzenie draftów, manipulacja kontekstem). To jest właśnie powód, dla którego ataki na dodatki mogą być bardziej niebezpieczne niż zwykłe okno phishingowe w przeglądarce.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla organizacji i użytkowników:

  • Przejęcie kont (ATO) – jeśli użytkownik używał tego samego hasła gdzie indziej albo nie miał mocnych kontroli dostępu, skutki idą daleko poza Outlook.
  • Obejście „czujności” – phishing działa w panelu Outlooka, więc heurystyki typu „nie klikaj w linki” są mniej skuteczne; użytkownik „sam” uruchamia dodatek ze sklepu.
  • Ryzyko danych w skrzynce – przy szerokich uprawnieniach dodatku potencjalnie w grę wchodzi wyciek informacji z maili i nadużycia w korespondencji.
  • Trudniejsze wykrywanie – to nie musi przechodzić przez klasyczne bramki pocztowe, a treść może być hostowana na legitnej infrastrukturze (np. platformy hostingowe), co utrudnia blokowanie domen „hurtowo”.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SOC / IT (organizacje)

  1. Inwentaryzacja dodatków Office/Outlook
    Sprawdź, jakie add-ins są zainstalowane/używane w tenantcie i przez kogo (szczególnie dodatki z marketplace).
  2. Zasada najmniejszych uprawnień
    Przeglądaj dodatki proszące o wysokie uprawnienia (np. ReadWriteItem). Jeśli nie są krytyczne biznesowo – usuń/ogranicz.
  3. Polityki dopuszczania dodatków (allowlist)
    Jeśli środowisko na to pozwala, przejdź na model „tylko zatwierdzone dodatki”.
  4. Detekcje wokół logowań i anomalii
    Monitoruj nietypowe logowania, skoki geolokalizacji, masowe próby, a także sygnały „impossible travel” i nietypowe aplikacje/klienty.
  5. Szybkie działania naprawcze, jeśli dodatek był używany
    Reset haseł, wymuszenie ponownego MFA, przegląd reguł skrzynki (inbox rules), sesji i urządzeń, oraz analiza zdarzeń dostępu.

Dla użytkowników końcowych

  • Jeśli dodatek wyświetla logowanie „Microsoft” w panelu, traktuj to jako czerwoną flagę (szczególnie, gdy wcześniej tego nie robił).
  • Zgłaszaj nietypowe zachowanie dodatków do IT; nie „próbuj jeszcze raz”.

Różnice / porównania z innymi przypadkami

Klasyczny phishing zwykle zaczyna się od wiadomości i linku. Tu dystrybucja odbywała się przez zaufany marketplace i UI Outlooka, a użytkownik nie musiał klikać w podejrzany e-mail. To upodabnia zdarzenie do:

  • przejęć rozszerzeń przeglądarkowych,
  • kompromitacji paczek w repozytoriach (npm/pypi),
  • przejęć domen po wygaśnięciu.

Wspólny mianownik: zmiana zachowania po pierwotnym „zaufaniu” i brak ciągłej weryfikacji treści po stronie dystrybutora.

Podsumowanie / kluczowe wnioski

Incydent „AgreeTo” pokazuje, że w 2026 r. ryzyko nie dotyczy już tylko „plików wykonywalnych” czy linków w mailach. Dynamiczne komponenty SaaS i dodatki stają się pełnoprawnym wektorem ataku łańcucha dostaw.

Najważniejsze wnioski:

  • Dodatki Office to aplikacje webowe ładowane z URL – przejęcie URL = przejęcie treści dodatku.
  • Wysokie uprawnienia (np. ReadWriteItem) mogą zamienić „niewinny” dodatek w narzędzie do eksfiltracji danych.
  • Organizacje powinny traktować marketplace add-ins jak software supply chain: inwentaryzacja, allowlisting, monitoring, przegląd uprawnień.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu „AgreeTo”, przejęcie URL i phishing na 4k kont (BleepingComputer)
  2. Koi Security – raport „AgreeToSteal” (mechanika ataku, skala, IOCs) (koi.ai)
  3. The Hacker News – streszczenie i kontekst supply chain, odniesienia do procesu publikacji (The Hacker News)
  4. Microsoft Learn – „Understanding Outlook add-in permissions” (m.in. ReadWriteItem) (Microsoft Learn)
  5. Microsoft Learn – „Browsers and webview controls used by Office Add-ins” (model webview/iframe) (Microsoft Learn)