Phishing gehört weiterhin zu den erfolgreichsten Methoden, um Unternehmen zu infiltrieren. Wir, bei Varonis haben eine große Menge an Malware-Infektionen beobachtet, die ihren Ursprung darin hatten, dass Benutzer durch das Öffnen infizierter Anhänge oder durch das Anklicken von Links auf bösartige Websites geleitet wurden, welche dann angreifbare Browser oder Plugins attackiert haben.
Parallel zu einer schnellen Umstellung auf Microsoft 365 in Unternehmen erleben wir jetzt ein neues Ziel: Den Angriffsvektor: Azure-Anwendungen.
Wie Sie im Folgenden sehen werden, können Angreifer für ihre Phishing-Kampagnen jetzt bösartige Azure-Apps erstellen, tarnen und verbreiten. Azure-Apps müssen nicht von Microsoft zugelassen werden und – was noch wichtiger ist – sind nicht auf die Ausführung von Code auf dem Rechner des Benutzers angewiesen. So können Sie der Erkennung auf Endgeräten durch Antivirusanwendungen leider allzu oft entgehen.
Sobald ein Angreifer seine Zielperson dazu gebracht hat, die bösartige App durch Anklicken zu installieren, kann er die gesamte Organisation des Benutzers erfassen, sich Zugriff auf die Dateien des Opfers verschaffen, seine E-Mails lesen, in seinem Namen E-Mails verschicken (was sich hervorragend für internes Spear-Phishing eignet) und noch viel mehr anrichten.
Microsoft hat den Azure App Service eingeführt, um Benutzern die Möglichkeit zu geben, individuelle Cloud-Anwendungen zu erstellen, die unkompliziert Azure APIs und Ressourcen aufrufen und nutzen können. Damit lassen sich relativ einfach leistungsfähige, anpassbare Programme erstellen, welche sich dann in das Microsoft 365-Ökosystem integrieren.
Zu den gebräuchlicheren Azure APIs gehört die MS Graph API. Diese API ermöglicht eine Interaktion der Apps mit der 365-Umgebung des Benutzers – was Benutzer, Gruppen, OneDrive Dokumente, Exchange Online-Postfächer und Konversationen umfasst.
So wie Ihr iOS-Telefon Sie fragen würde, ob Sie eine App auf Ihre Kontakte oder Standortdaten zugreifen lassen möchten, wird der Benutzer beim Azure App-Autorisierungsprozess gebeten, der App den Zugriff auf die Ressourcen zu gewähren, die diese benötigt. Ein gerissener Angreifer kann diese Chance nutzen, um den Benutzer dazu zu bringen, unbeabsichtigt seiner bösartigen App Zugriff auf eine oder mehrere sensible Cloud-Ressourcen zu gewähren.
Um diesen Angriff auszuführen, benötigt der Angreifer eine Webanwendung und einen Azure-Mandanten zum Hosten. Nachdem dafür gesorgt ist, können wir eine Phishing-Kampagnen mit einem Link auf die Azure-App verbreiten:
Der Link in der E-Mail leitet den Benutzer auf eine, vom Angreifer kontrollierte Website (z. B. https://myapp.malicious.com), die das Opfer nahtlos auf seine Microsoft Anmeldeseite weiterleitet. Der Authentifizierungsablauf wird dann komplett von Microsoft gemanaget, weshalb eine Multi-Faktor-Authentifizierung kein gangbares Gegenmittel ist.
Sobald sich der Benutzer bei seiner O365-Instanz angemeldet hat, wird für unsere bösartige App ein Token generiert und der Benutzer wird zur Autorisierung und Erteilung der von ihr benötigten Berechtigungen aufgefordert.
Und so sieht das für den Endanwender aus (also sehr ähnlich wie beim Installieren von Apps in SharePoint oder Teams):
Aus Sicht des Angreifers sind dies die MS Graph API-Berechtigungen, die wir im Code unserer App anfordern:
Wie Sie sehen, hat der Angreifer die Kontrolle über den Namen der Anwendung (wir haben „MicrosoftOffice“ gewählt) und das Symbol (wir haben das OneNote-Symbol verwendet). Die URL ist eine gültige Microsoft URL, das Zertifikat ist valide.
Unter dem Namen der Anwendung ist jedoch der Name des Mandanten des Angreifers und ein Warnhinweis zu sehen, die beide nicht ausgeblendet werden können. Der Angreifer hofft, dass der Benutzer es eilig haben wird, das vertraute Symbol sieht und den Bildschirm nur überfliegt, ohne nachzudenken, wie es auch beim Bestätigen von Nutzungsbedingungen der Fall wäre.
Durch Anklicken von „Akzeptieren“ erteilt das Opfer unserer Anwendung die Berechtigung im Namen seiner Benutzer – die Anwendung kann also die E-Mails des Benutzers auslesen und auf alle Dateien zugreifen, zu denen der Benutzer Zugang hat.
Dieser Schritt ist der einzige, bei dem das Opfer Zustimmung erteilen muss – von diesem Punkt an hat der Angreifer die vollständige Kontrolle über das Konto und die Ressourcen des Benutzers.
Nach Erteilen des Zustimmung für die Anwendung wird das Opfer auf eine Website unserer Wahl weitergeleitet. Ein netter Trick ist, die letzten Dateizugriffe des Benutzers zu mappen und ihn auf ein internes SharePoint-Dokument weiterzuleiten, um den Vorgang weniger verdächtig wirken zu lassen.
Dieser Angriff eignet sich hervorragend für:
Um die Gefahr, die von Azure-Apps ausgeht, zu illustrieren, haben wir eine lustige Konsole programmiert, die zeigt, auf welche Ressourcen wir mit unserem Proof-of-Concept Zugriff erlangt haben:
Die Ich-Option präsentiert das Opfer unseres Phishing-Angriffs:
Benutzer zeigt und die oben angeführten Metadaten für jeden einzelnen Benutzer im Unternehmen, inklusive E-Mail-Adresse, Mobiltelefonnummer, Stellenbezeichnung und mehr (was von den Active Directory-Attributen im Unternehmen abhängt). Schon dieser API-Aufruf alleine könnte eine massive Datenschutzverletzung sein, insbesondere gemäß DSGVO und CCPA.
Die Option Kalender zeigt uns die Kalendereinträge des Opfers an. Wir könnten also in seinem Namen Termine erstellen, vorhandene Termine anzeigen und sogar Zeiten in seinem Arbeitstag frei machen, indem wir für die Zukunft geplante Termine löschen.
Die möglicherweise kritischste Funktion in unserer Konsolen-App ist die Funktion Letzte Dateien, mit der wir uns alle Dateien ansehen können, auf die der Benutzer in OneDrive oder SharePoint zugegriffen hat. Wir können auch Dateien herunterladen oder ändern. (Bösartige Makros für dauerhaften Zugriff gefällig?)
ACHTUNG: Wenn wir mit dieser API auf eine Datei zugreifen, erstellt Azure einen eindeutigen Link. Auf diesen Link kann jedermann von jedem beliebigen Ort aus zugreifen – selbst wenn das Unternehmen den normalen O365-Benutzern kein anonymes Freigeben gestattet.
API-Links sind etwas Besonderes. Wir wissen ehrlich gesagt nicht, warum die Link-Freigaberichtlinie des Unternehmens sie nicht blockiert. Es könnte aber sein, dass Microsoft damit Fehlfunktionen bei benutzerdefinierten Apps infolge von Richtlinienänderungen verhindern will. Eine Anwendung kann einen Download-Link oder Änderungslink für eine Datei anfordern – in unserem PoC haben wir beides getan.
Die Option Outlook verschafft uns vollständigen Zugriff auf das E-Mail-Postfach unseres Opfers. Wir können die Empfänger aller Nachrichten sehen, nach Nachrichten mit hoher Priorität filtern, E-Mails versenden (z. B. um andere Benutzer mit Spear-Phishing anzugreifen) und mehr.
Durch die Lektüre des E-Mails des Benutzers können wir die üblichen und angreifbarsten Kontakte identifizieren, interne Spear-Phishing-E-Mails mit dem Opfer als Absender versenden und seine Kollegen infizieren. Außerdem können wir das E-Mail-Konto des Opfers verwenden, um Daten zu exfiltrieren, die wir in O365 gefunden haben.
Darüber hinaus lässt uns Microsoft Erkenntnisse über die Kollegen des Opfers, die diese API verwenden, gewinnen. Die Daten über Kollegen können benutzt werden, um andere Benutzer zu identifizieren, mit denen das Opfer am meisten interagiert:
Wie oben erwähnt, können wir mit den richtigen Berechtigungen die Dateien des Benutzers verändern. Nur was könnten wir bloß mit einer API zur Veränderung von Dateien anfangen….?😊
Eine Option wäre, unsere bösartige Azure-App in Ransomware zu verwandeln, die aus der Ferne Dateien verschlüsselt, auf die der Benutzer in SharePoint und OneDrive zugreifen kann:
Diese Methode der Verschlüsselung bietet zwar keine Erfolgsgarantie, weil einige Dateien mithilfe strengerer Einstellungen für Sicherungskopien wiederherstellbar sein könnten, bei Mandanten mit Standardeinstellungen besteht jedoch die Gefahr eines endgültigen Datenverlustes. Andererseits könnten wie immer sensible Daten exfiltrieren und drohen, sie öffentlich verfügbar zu machen, wenn keine Lösegeldzahlung erfolgt.
Andere Ressourcen:
Diese Phishing-Technik ist gegenwärtig noch relativ unbekannt. Viele Sicherheitsverantwortliche sind sich des Schadens, den ein Angreifer dadurch verursachen kann, dass ein einziges Opfer einer bösartigen Azure-App Berechtigungen erteilt, nicht bewusst. Die Zustimmung zu einer Azure-App unterscheidet sich nicht sehr stark davon, eine bösartige exe-Datei auszuführen oder die Ausführung von Makros in einem Dokument unbekannter Herkunft zuzulassen – aber weil es sich um einen neuen Vektor handelt, bei dem kein Code auf dem Endgerät ausgeführt werden muss, ist dieser Angriff schwieriger zu erkennen und zu blockieren.
Laut Microsoft ist es nicht empfehlenswert, Benutzern die Möglichkeit zu entziehen, Anwendungen zuzustimmen:
„Sie können integrierte Anwendungen für Ihren Mandanten ausschalten. Das ist ein drastischer Schritt, mit dem den Benutzern mandantenweit die Möglichkeit genommen wird, ihre Zustimmung zu erteilen. Dadurch kann verhindert werden, dass Ihre Benutzer unbeabsichtigt einer bösartigen Anwendung Zugriffsberechtigungen einräumen. Es wird aber nicht wirklich empfohlen, weil es die Fähigkeit Ihrer Benutzer, mit Drittanwendungen produktiv zu arbeiten, massiv einschränkt.“
Die einfachste Methode zur Erkennung von unzulässigen Berechtigungserteilungen ist die Überwachung von Genehmigungsereignissen im Azure AD und die regelmäßige Überprüfung Ihrer „Unternehmensanwendungen“ im Azure-Portal.
Stellen Sie sich selbst diese Fragen:
Für Varonis-Kunden: DatAlert enthält Bedrohungsmodelle, mit denen die unzulässige Erteilung von Berechtigungen erkannt wird. Sie können außerdem individuelle Regeln erstellen, mit denen spezielle Benachrichtigungen bezüglich aller Anwendungen, für die eine Genehmigung erteilt wurde, ausgegeben werden.
Bitte wenden Sie sich an Varonis-Sales oder den Varonis-Support, um sicherzustellen, dass Sie die aktuelle Version von DatAlert installiert und die richtigen Bedrohungsmodelle aktiviert haben.
Navigieren Sie im Azure-Portal auf der Registerkarte „Azure Active Directory“ zu „Unternehmensanwendungen“ und löschen Sie die Anwendungen. In gewöhnlicher Benutzer kann den Zugriff auch löschen, indem er https://myapps.microsoft.com aufruft, die dort aufgeführten Apps überprüft und nach Bedarf Berechtigungen löscht.
Eine detaillierte Beschreibung finden Sie unter: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants