Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure-Anwendungen fragen nach Berechtigungen, um auf die Benutzerdaten (Basisinformationen, aber auch Zugriff auf Dokumente, E-Mails senden...) zuzugreifen.
Wenn erlaubt, kann ein normaler Benutzer nur für "Low Impact"-Berechtigungen Zustimmung erteilen. In allen anderen Fällen ist Admin-Zustimmung erforderlich.
GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zur Erteilung von Berechtigungen an Anwendungen umfasst, können eine tenantweite Zustimmung erteilen.
Nur Berechtigungen, die keine Admin-Zustimmung erfordern, werden als niedriges Risiko klassifiziert. Dies sind Berechtigungen, die für die grundlegende Anmeldung erforderlich sind: openid, profil, email, User.Read und offline_access. Wenn eine Organisation **Benutzerzustimmung für alle Apps erlaubt, kann ein Mitarbeiter einer App die Zustimmung erteilen, um die oben genannten Informationen aus seinem Profil zu lesen.
Daher könnte ein Angreifer eine bösartige App vorbereiten und mit einem Phishing den Benutzer dazu bringen, die App zu akzeptieren und seine Daten zu stehlen.
Unauthenticated: Erstellen Sie von einem externen Konto aus eine Anwendung mit den Berechtigungen User.Read und User.ReadBasic.All, phishen Sie einen Benutzer, und Sie können auf Verzeichnisinformationen zugreifen.
Dies erfordert, dass der phishing Benutzer in der Lage ist, OAuth-Apps aus externen Umgebungen zu akzeptieren!
Authenticated: Nachdem Sie einen Principal mit ausreichenden Berechtigungen kompromittiert haben, erstellen Sie eine Anwendung im Konto und phishen Sie einen privilegierten Benutzer, der privilegierte OAuth-Berechtigungen akzeptieren kann.
In diesem Fall können Sie bereits auf die Informationen des Verzeichnisses zugreifen, sodass die Berechtigung User.ReadBasic.All nicht mehr interessant ist.
Sie sind wahrscheinlich an Berechtigungen interessiert, die eine Zustimmung des Administrators erfordern, da normale Benutzer OAuth-Apps keine Berechtigungen erteilen können, weshalb Sie nur diese Benutzer phishen müssen (mehr dazu, welche Rollen/Berechtigungen dieses Privileg gewähren, später).
Der folgende PowerShell-Befehl wird verwendet, um die Zustimmungskonfiguration für Benutzer in Azure Active Directory (Azure AD) hinsichtlich ihrer Fähigkeit zur Zustimmung zu Anwendungen zu überprüfen:
Benutzerzustimmung deaktivieren: Diese Einstellung verbietet es Benutzern, Anwendungen Berechtigungen zu gewähren. Keine Benutzerzustimmung zu Anwendungen ist erlaubt.
Benutzer können Apps von verifizierten Herausgebern oder Ihrer Organisation zustimmen, jedoch nur für die von Ihnen ausgewählten Berechtigungen: Diese Einstellung erlaubt es allen Benutzern, nur Anwendungen zuzustimmen, die von einem verifizierten Herausgeber veröffentlicht wurden und Anwendungen, die in Ihrem eigenen Mandanten registriert sind. Sie fügt eine Kontrollschicht hinzu, indem sie Zustimmung nur für bestimmte Berechtigungen erlaubt.
Benutzer können allen Apps zustimmen: Diese Einstellung ist großzügiger und erlaubt es allen Benutzern, für Anwendungen allen Berechtigungen zuzustimmen, solange diese Berechtigungen keine administrative Zustimmung erfordern.
Benutzerdefinierte App-Zustimmungspolitik: Diese Einstellung zeigt an, dass eine benutzerdefinierte Richtlinie vorhanden ist, die an spezifische organisatorische Anforderungen angepasst werden kann und möglicherweise eine Kombination von Einschränkungen basierend auf dem App-Herausgeber, den angeforderten Berechtigungen der App und anderen Faktoren umfasst.
Bei einem Angriff durch illegale Zustimmung tricksen Angreifer Endbenutzer, indem sie ihnen die Berechtigung erteilen, einer bösartigen Anwendung, die bei Azure registriert ist, zuzustimmen. Dies geschieht, indem die Anwendung legitim erscheint, was die Opfer dazu führt, unwissentlich auf eine "Akzeptieren"-Schaltfläche zu klicken. Infolgedessen gibt Azure AD ein Token an die Website des Angreifers aus, das ihnen den Zugriff auf und die Manipulation der Daten des Opfers ermöglicht, wie z.B. das Lesen oder Senden von E-Mails und den Zugriff auf Dateien, ohne ein organisatorisches Konto zu benötigen.
Der Angriff umfasst mehrere Schritte, die auf ein generisches Unternehmen abzielen. So könnte es ablaufen:
Domainregistrierung und Anwendungs-Hosting: Der Angreifer registriert eine Domain, die einer vertrauenswürdigen Website ähnelt, z.B. "safedomainlogin.com". Unter dieser Domain wird eine Subdomain erstellt (z.B. "companyname.safedomainlogin.com"), um eine Anwendung zu hosten, die darauf ausgelegt ist, Autorisierungscodes zu erfassen und Zugriffstoken anzufordern.
Anwendungsregistrierung in Azure AD: Der Angreifer registriert dann eine Multi-Tenant-Anwendung in seinem Azure AD-Mandanten und benennt sie nach dem Zielunternehmen, um legitim zu erscheinen. Er konfiguriert die Redirect-URL der Anwendung so, dass sie auf die Subdomain verweist, die die bösartige Anwendung hostet.
Einrichten von Berechtigungen: Der Angreifer richtet die Anwendung mit verschiedenen API-Berechtigungen ein (z.B. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Diese Berechtigungen erlauben es dem Angreifer, sensible Informationen im Namen des Benutzers zu extrahieren, sobald sie vom Benutzer gewährt werden.
Verbreitung bösartiger Links: Der Angreifer erstellt einen Link, der die Client-ID der bösartigen Anwendung enthält, und teilt ihn mit gezielten Benutzern, um sie zu täuschen und zur Zustimmung zu bewegen.
Der Angriff kann mit Tools wie 365-Stealer erleichtert werden.
Wenn der Angreifer einen gewissen Zugang zu einem Benutzer in der Opferorganisation hat, könnte er überprüfen, ob die Richtlinie der Organisation es dem Benutzer erlaubt, Apps zu akzeptieren:
Um den Angriff auszuführen, müsste der Angreifer eine neue App in seinem Azure-Mandanten (in App-Registrierungen) erstellen, die mit den Berechtigungen konfiguriert ist:
User.ReadBasic.All befindet sich in Microsoft Graph in Delegierten Berechtigungen. (Anwendungsberechtigungen benötigen immer eine zusätzliche Genehmigung).
User.ReadBasic.All ist die Berechtigung, die es Ihnen ermöglicht, Informationen über alle Benutzer in der Organisation zu lesen, wenn sie gewährt wird.
Denken Sie daran, dass nur GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zur Gewährung von Berechtigungen an Anwendungen umfasst, eine mandantenweite Zustimmung erteilen können. Daher sollten Sie einen Benutzer mit einer dieser Rollen phishing, wenn Sie möchten, dass er eine App genehmigt, die eine Administratorgenehmigung erfordert.
Sie könnten auch eine App über die CLI mit folgendem Befehl erstellen:
Überprüfen Sie https://www.alteredsecurity.com/post/introduction-to-365-stealer, um zu erfahren, wie Sie es konfigurieren.
Beachten Sie, dass das erhaltene Zugriffstoken für den Graph-Endpunkt mit den Berechtigungen: User.Read und User.ReadBasic.All (den angeforderten Berechtigungen) sein wird. Sie werden keine anderen Aktionen durchführen können (aber diese sind ausreichend, um Informationen über alle Benutzer in der Organisation herunterzuladen).
Sie könnten auch dieses Tool verwenden, um diesen Angriff durchzuführen.
Sobald Sie Zugriff auf den Benutzer haben, können Sie Dinge tun wie das Stehlen sensibler Dokumente und sogar das Hochladen von mit Backdoors versehenen Dokumentdateien.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
