Erstmals ist ein bösartiges Microsoft Outlook Add in bekannt geworden, das nachweislich im realen Einsatz verteilt wurde und dabei nicht durch eine neue Einreichung in den Store, sondern durch die Übernahme einer bestehenden Infrastruktur auffiel. Der ursprüngliche Entwickler des Add ins gilt dabei nicht als Angreifer. Vielmehr nutzte ein Dritter eine strukturelle Schwäche im Lebenszyklus von Office Add ins aus: die Abhängigkeit von einer extern gehosteten Web Adresse, deren Kontrolle später wechseln kann.
Ausgangspunkt: Ein legitimes Add in namens AgreeTo
Im Jahr 2022 veröffentlichte ein Entwickler ein Terminplanungswerkzeug namens AgreeTo im Microsoft Office Add in Store. Das Add in war auf die Planung von Meetings ausgelegt und erhielt in diesem Kontext Berechtigungen, die für die Funktionalität plausibel erscheinen. Parallel existierte eine Chrome Erweiterung mit Nutzerbasis und Bewertungen. Das Projekt war als ernsthaftes Produkt angelegt, inklusive Quellcode Verwaltung und Integrationen in gängige Schnittstellen.
Zu den genannten Komponenten zählten:
- eine Codebasis als TypeScript Monorepo
- Integration der Microsoft Graph API
- Unterstützung für Google Calendar
- Abrechnung über Stripe
Der Betrieb wurde später eingestellt. Updates blieben aus, eine zugehörige Domain lief ab, und Nutzer bemerkten Funktionsausfälle. Während die Chrome Erweiterung schließlich entfernt wurde, blieb das Outlook Add in weiterhin im Office Store gelistet.
Technischer Hintergrund: Warum Office Add ins ein besonderes Risiko darstellen
Office Add ins bestehen in der Praxis nicht aus lokal installiertem Programmcode. Stattdessen wird ein Manifest bei Microsoft eingereicht. Dieses Manifest ist eine XML Datei, die im Kern definiert, welche Web Adresse innerhalb eines eingebetteten Browser Kontextes geladen wird, typischerweise in einem iframe innerhalb der Outlook Seitenleiste.
Microsoft prüft das Manifest, signiert es und stellt den Eintrag im Store bereit. Die eigentliche Oberfläche und Logik des Add ins werden jedoch bei jeder Nutzung live von der angegebenen Server Adresse geladen. Damit entsteht eine dynamische Abhängigkeit: Was der Server aktuell ausliefert, ist das, was in Outlook ausgeführt wird.
Besonders relevant ist in diesem Fall eine Berechtigung aus dem Manifest: ReadWriteItem. Diese Berechtigung erlaubt dem Add in, Inhalte im Postfach zu lesen und zu verändern. Für ein Terminplanungswerkzeug kann das sachlich begründbar sein. Wenn jedoch später ein anderer Betreiber die zugrundeliegende Web Adresse kontrolliert, bleibt die Berechtigung bestehen, obwohl sich die ausgelieferte Funktionalität vollständig ändern kann.
Der Wendepunkt: Übernahme einer ehemals legitimen Deployment Adresse
Das gelistete Add in verwies auf eine über Vercel gehostete Adresse. Nachdem der ursprüngliche Entwickler das Deployment entfernte, wurde die Subdomain erneut registrierbar. Ein Angreifer übernahm diese Adresse und ersetzte die ursprüngliche Anwendung durch ein Phishing Paket. Eine erneute Prüfung durch Microsoft war dafür laut Bericht nicht erforderlich, da der Store Eintrag bereits existierte und die Infrastruktur den Inhalt weiterhin auslieferte.
Damit entstand ein kritisches Szenario: Microsoft signierte das Manifest zu einem früheren Zeitpunkt, überprüfte jedoch offenbar nicht fortlaufend, welche Inhalte die referenzierte Adresse später bereitstellt.
Angriffsablauf: Phishing innerhalb einer vertrauenswürdigen Outlook Umgebung
Beim Öffnen des Add ins sahen Betroffene dem Bericht zufolge keine Terminplanung, sondern eine nachgebildete Microsoft Anmeldeseite. Der Ablauf war aus technischer Sicht vergleichsweise schlicht, jedoch im Kontext von Outlook besonders wirksam:
- Opfer öffnen das Add in in Outlook und erhalten eine Login Aufforderung
- Eingaben wie E Mail Adresse und Passwort werden per JavaScript erfasst
- Zusätzlich wird die IP Adresse des Opfers mitgesendet
- Die Daten werden über die Telegram Bot API an den Angreifer exfiltriert
- Nach kurzer Ladeanzeige erfolgt eine Weiterleitung zur echten Anmeldeseite unter login.microsoftonline.com
Durch die Weiterleitung wirkt der Vorgang für Nutzer plausibel, etwa als doppelte Anmeldung. Gleichzeitig reduziert die Ausführung im Outlook Kontext die Wahrscheinlichkeit, dass klassische Sicherheitsindikatoren auffallen. Der Bericht betont, dass der eigentliche Effekt nicht durch eine neue Phishing E Mail erzielt wurde, sondern durch die Einbettung in ein von Microsoft verteiltes Add in mit Zustimmung zu Berechtigungen.
Ausmaß: Tausende kompromittierte Konten und weitere Finanzdaten
Da der Office Store keine Installationszahlen anzeigt, war die Reichweite zunächst unklar. Laut Bericht gelang es den Forschenden jedoch, Zugriff auf den Exfiltrationskanal des Angreifers zu erhalten. Dadurch konnte der Umfang rekonstruiert werden. Genannt werden mehr als 4.000 kompromittierte Datensätze, darunter Microsoft Zugangsdaten sowie zusätzlich erbeutete Kreditkarteninformationen und Sicherheitsantworten aus Banking Kontexten. Zudem wird beschrieben, dass gestohlene Zugangsdaten noch am Vortag aktiv getestet worden seien und die Infrastruktur zum Zeitpunkt der Analyse weiter betrieben wurde.
Über das Outlook Add in hinaus identifizierten die Forschenden nach eigener Darstellung weitere Phishing Kits des gleichen Akteurs, die verschiedene Marken imitieren, darunter Internet Provider, Banken und Webmail Anbieter. Der Outlook Kanal sei demnach nur eine von mehreren Verteilungsvarianten innerhalb einer professionell aufgestellten Kampagne.
Warum klassische Schutzmechanismen hier an Grenzen stoßen
Der Fall illustriert eine Lücke zwischen Store Prüfung und laufender Inhaltsauslieferung. Der Bericht nennt mehrere Gründe, warum Standardmaßnahmen das Szenario schwer erfassen:
- Mail Gateways sehen den Phishing Inhalt nicht, da keine Phishing Nachricht zugestellt wird
- Endpoint Schutz kann unauffälliger bleiben, weil JavaScript im legitimen Outlook Prozess ausgeführt wird
- URL Filterung ist erschwert, weil vercel.app ein legitimer Hosting Dienst für sehr viele Anwendungen ist
Die zentrale Schwachstelle liegt jedoch in der Architektur: Add ins laden mutable Inhalte von einer Web Adresse. Eine Prüfung zum Zeitpunkt der Store Aufnahme kann nicht garantieren, dass Jahre später noch dieselbe Anwendung ausgeliefert wird. In diesem Fall kam hinzu, dass die vom Add in deklarierte Berechtigung ReadWriteItem theoretisch weitreichendere Angriffe erlaubt hätte, etwa das stille Auslesen des Postfachs oder das Versenden von Nachrichten im Namen der Betroffenen.
Einordnung: Vorhersage aus der Sicherheitsforschung
Der Bericht verweist auf frühere Arbeiten von Sicherheitsforschenden, die Office Add ins bereits 2019 als Angriffsfläche beschrieben und die Möglichkeit einer Instrumentalisierung zur persistenten Postfach Kompromittierung demonstriert hätten. Der aktuelle Fall wird als praktische Realisierung dieses Risikos gewertet, begünstigt durch fehlende oder unzureichende Nachkontrolle der ausgelieferten Inhalte nach der ursprünglichen Freigabe.
Indikatoren und Meldeschritte
Als technische Indikatoren werden unter anderem genannt:
- outlook one vercel app als Phishing Domain
- WA200004949 als Office Add in Kennung
Nach Darstellung des Berichts wurden Meldungen an Microsoft zur Entfernung aus dem Office Store sowie Abuse Reports an Vercel und Telegram eingereicht. Betroffene, deren Daten im Exfiltrationsverlauf identifiziert werden konnten, seien soweit möglich benachrichtigt worden.
Fazit: Store Signatur ersetzt keine fortlaufende Inhaltskontrolle
Der Fall zeigt, wie ein aufgegebenes Add in aufgrund seiner dynamischen Bereitstellungslogik zu einem Angriffswerkzeug werden kann. Entscheidend war nicht die Raffinesse der Phishing Technik, sondern die Vertrauenskette: ein zuvor geprüftes Manifest, eine später übernommene Web Adresse und eine Ausführung innerhalb einer vertrauten Outlook Oberfläche mit bestehenden Berechtigungen. Aus Sicht der IT Sicherheit unterstreicht der Vorfall die Notwendigkeit, nicht nur Manifeste, sondern auch die fortlaufend ausgelieferten Inhalte und die Ownership der referenzierten Ressourcen kontinuierlich zu überwachen.
