Power Automate, ehemals Microsoft Flow, ermöglicht es Benutzern, Arbeitsabläufe zwischen verschiedenen Anwendungen und Diensten zu automatisieren. Mit Power Automate können Sie „Flows“ (Abläufe) in Microsoft 365 für Outlook, SharePoint und OneDrive erstellen, um automatisch Dateien zu teilen oder zu versenden, E-Mails weiterzuleiten und vieles mehr.
Obwohl diese Funktion für alltägliche Automatisierungsaufgaben sehr leistungsstark ist, kann sie auch von Bedrohungsakteuren genutzt werden, um die Datenexfiltration, die C2-Kommunikation und die laterale Bewegung zu automatisieren sowie DLP-Lösungen zu umgehen.
Power Automate ist in Microsoft-365-Anwendungen standardmäßig aktiviert. Jeder Benutzer kann damit eigene Abläufe erstellen. Diese können programmatisch oder mit Hilfe der Benutzeroberfläche des Ablaufplaners erstellt werden.
Um einen Ablauf zu erstellen, muss ein Benutzer zunächst eine Verbindung erstellen. Diese Verbindung ermöglicht dem Ablauf den Zugriff auf die Anwendung oder Ressource mit den Berechtigungen des Benutzers.
Sobald die Verbindung hergestellt und der Ablauf gespeichert ist, wird er ausgeführt. Jede Aktivität, die durch den Ablauf ausgeführt wird, wird unter dem Benutzer protokolliert, der die Verbindung erstellt hat.
Das lässt sich in dem folgenden beispielhaften Protokoll von compliance.microsoft.com/auditlogsearch beobachten.
Ähnlich wie die Weiterleitungsregeln in E-Mail-Clients für die Exfiltration verwendet werden können, können Abläufe in Power Automate benutzt werden, um nicht nur E-Mails, sondern auch Dateien aus SharePoint und OneDrive zu extrahieren. Es lassen sich auch Daten aus anderen Microsoft-365-Anwendungen exfiltrieren (sogar aus MSGraph).
Schauen wir uns einige Beispiele an.
Dies ist keine Weiterleitungsregel in Outlook/Exchange, daher werden Erkennungs- und Präventionsmaßnahmen für die Erstellung von Weiterleitungsregeln diese Aktion nicht blockieren oder erkennen.
Der folgende Ablauf erstellt einen anonymen Freigabelink für jede Datei, die auf der SharePoint-Site erstellt wurde und auf die der Benutzer Zugriff hat. Anschließend POSTet er den Link über einen API-Aufruf an den Server des Angreifers.
Wenn Sie einen Ablauf erstellen, der die Dateierstellung als Auslöser verwendet (d. h. wenn eine Datei erstellt wird, wird X getan), überwacht der Ablauf jede auf der SharePoint-Site erstellte Datei, auch wenn der Ablaufbesitzer die Datei nicht selbst erstellt hat. Wenn der Besitzer des Ablaufs berechtigt ist, die Datei anzuzeigen, wird der Ablauf ausgelöst.
In den meisten Umgebungen sind die SharePoint-Berechtigungen kompliziert und schwer zu verwalten. Infolgedessen haben viele Benutzer übermäßigen Zugriff auf Informationen, die sie nicht benötigen, wodurch Angreifer viel Schaden anrichten können.
Wenn der Ablauf für ein paar Tage deaktiviert wird, werden die verpassten Dateierstellungen praktischerweise bei erneuter Aktivierung erfasst und an den Angreifer gesendet.
Die Erstellung von Abläufen kann programmatisch über die Ablauf-API erfolgen. Obwohl es keine eigene Power-Automate-API gibt, können die Ablaufendpunkte verwendet werden, um vorhandene Verbindungen abzufragen und einen Ablauf zu erstellen.
Unser Skript demonstriert die Vorgehensweise eines Angreifers bei der Kompromittierung geschäftlicher E-Mails.
Sobald ein Microsoft-365-Konto kompromittiert ist, können Angreifer einfach einen Befehl ausführen, der eingehende vertrauliche Daten weitergibt, ohne den Power-Automate-Ablauf manuell erstellen zu müssen.
Das folgende Skript erstellt einen Ablauf namens „E-Mail-Weiterleitung“, der alle eingehenden E-Mails automatisch an den Posteingang des Angreifers weiterleitet.
Der Ablauf wird dann in der Benutzeroberfläche angezeigt und aktiviert:
Der Name des Ablaufs ist anpassbar, daher kann er auch einen eher obskuren Namen erhalten.
Schädliche Abläufe können auch für andere Aktivitäten verwendet werden, z. B. zum Abrufen von Organisationsbäumen aus Delve, zum Erfassen von Dateistatistiken in SharePoint und für weitere Zwecke.
Wie wir in unserer früheren Untersuchung bereits erläutert haben, können Angreifer Benutzer derart täuschen, dass sie bösartige Azure-Anwendungen installieren, die wie offizieller, von Microsoft genehmigter Code wirken.
Sobald ein Benutzer die bösartige Azure-Anwendung installiert hat, kann ein Bedrohungsakteur Power Automate nutzen, ohne dafür Zugriff auf die Zugangsdaten des Kontos zu benötigen.
Zunächst erstellen wir eine Anwendung in unserem Angreifer-Mandanten und senden einen Link an das Opfer. Wenn das Opfer auf den Link klickt, wird es automatisch zur Zustimmungs-Landing-Page von Azure für die Anwendung weitergeleitet. Sobald der Benutzer zustimmt, verfügt unsere Anwendung über die notwendigen Berechtigungen, um einen Ablauf zu erstellen.
Hier sehen wir unsere bösartige Anwendung, die die Zustimmung eines Benutzers zum Erstellen und Bearbeiten von Abläufen anfordert:
Die Anwendung authentifiziert die Anfrage mit einer gültigen Microsoft-Domäne und URL, was die Erfolgswahrscheinlichkeit erhöht.
Diese Methode hat einen Nachteil: Ich konnte keine Möglichkeit finden, eine neue Power-Automate-Verbindung mit der Azure-Anwendung zu erstellen. Ich kann nur vorhandene Verbindungen verwenden, da der Token der Anwendung keine Berechtigungen zum Erstellen einer Verbindung hat. Daher sind wir mit Azure-Anwendungen für diesen Angriff auf Benutzer beschränkt, die bereits Verbindungen über Power Automate hergestellt haben.
Die sicherste Methode wäre die Verwendung der Anmeldedaten des Benutzers oder eines Power-Automate-Authentifizierungstokens. Mit dieser Methode lassen sich Verbindungen und Abläufe programmatisch, ohne Benutzerinteraktion, und automatische Exfiltrationsabläufe nach Belieben erstellen.
Die von uns besprochenen Angriffe erläutern mehrere Vektoren, über die Bedrohungsakteure auf Power Automate in einem Unternehmen zugreifen können.
Varonis bietet nun verhaltensbasierte Alarme in Microsoft 365, die ungewöhnlichen Datenzugriff und E-Mail-Aktivitäten basierend auf den vergangenen Baseline-Daten des Benutzers erkennen können. Dies gilt unabhängig davon, ob die Aktionen manuell vom Benutzer, über Skripte oder mit Power Automate durchgeführt werden.
Das ist vielleicht die praktischste Verteidigungslinie gegen die Exfiltration mit Power Automate, da Sie keine spezifischen Erkennungsregeln schreiben oder manuell nach verdächtigen Änderungen an IP-Adressen oder Zeichenfolgen des Benutzer-Agenten suchen müssen.
Verhaltensbasierte Alarme sind auch äußerst effektiv darin, zu erkennen, ob ein Benutzer mit Malware infiziert ist, die im Kontext des Benutzers ausgeführt wird – es ist für Angreifer sehr schwer, das normale alltägliche Verhalten eines Benutzers nachzuahmen.
Azure AD überwacht jede Anmeldung in seinen Anmeldeprotokollen. Das ist leistungsstarkes Tool zur Überwachung des Ressourcenzugriffs.
In diesem Fall können wir die Anmeldungen bei Power Automate (auch bekannt als „Microsoft Flow Service“) überwachen und bei Anomalien warnen.
Das obige Anmeldeereignis zeigt, dass unser Skript unter dem Benutzer Ringo ausgeführt wird und sich authentifiziert Microsoft Flow Service mit der Anwendung Azure Active Directory PowerShell authentifiziert, was durchaus unerwartet ist. Für die reguläre Authentifizierung über die Benutzeroberfläche wird die Anwendung Microsoft Flow Portal verwendet.
Weitere Anomalien, auf die Sie achten können, sind:
Wir können uns die Ablaufprotokolle direkt ansehen, um uns ein Bild von den neu erstellten Abläufen zu machen:
Achten Sie darauf, wie in den Ablaufprotokollen jegliche Daten darüber fehlen, was genau sich im Ablauf geändert hat oder welcher Ablauf mit welcher Verbindung erstellt wurde. Wir können dies jedoch nutzen, um einen genaueren Blick darauf zu werfen, was passiert, nachdem sich der Benutzer bei der Power-Automate-Ressource authentifiziert hat. Es könnte sein, dass der Benutzer sich von jedem Standort aus anmelden, aber von dort keine Abläufe erstellen darf.
Automatische Aktionen, die von Power Automate durchgeführt werden, werden in den Protokollen durch den Benutzeragenten „azure-logic-apps/*“ angezeigt, wie hier zu sehen:
Ein weiterer Aspekt ist, dass die Aktion immer über eine Microsoft-IP erfolgt. Wenn wir uns jedoch zu sehr darauf verlassen, führt das womöglich zu vielen falsch-positiven Meldungen, da wir es mit einer Microsoft-Plattform zu tun haben.
Anhand dieses indikativen Benutzeragenten können wir entweder direkt bei verdächtigen Aktivitäten warnen oder die automatisierten Aktivitäten mit den regulären und früheren automatisierten Aktivitäten des Benutzers vergleichen, um Anomalien zu festzustellen.
Die Verwendung von Azure-Anwendungen für diesen Angriff erzeugt eine andere Protokollspur als die direkte Verwendung von Anmeldedaten. Wir können den Unterschied in den Azure AD-Anmeldeprotokollen sehen:
Die für die Authentifizierung verwendete Anwendung ist „MicrosoftOffice“. Dabei handelt es sich um unsere bösartige Anwendung (die sich zur Täuschung als „MicrosoftOffice“ bezeichnet), und die Ressource ist „Microsoft Flow Service“ (wie zuvor).
Die Überwachung oder Beschränkung der Authentifizierung auf den Flow Service nur für zugelassene Anwendungen schränkt die Angriffsfläche ein und hilft so, die Ausnutzung von Power Automate zu verhindern.
Die Überwachung der für Anwendungen erteilten Genehmigungen kann ebenfalls dazu beitragen, diesen und andere potenziell destruktive Angriffe zu verhindern.
Blockieren Sie direkt die Exfiltration per E-Mail, indem Sie Kontrollen für Konnektoren einrichten:
https://docs.microsoft.com/en-us/power-platform/admin/block-forwarded-email-from-power-automate