Az - Illicit Consent Grant
OAuth App Phishing
Azure Applications fragen nach Berechtigungen, um auf die Benutzerdaten zuzugreifen (Basisinformationen, aber auch Zugriff auf Dokumente, E-Mails senden...).
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 mandantenweite Zustimmung erteilen.
Nur Berechtigungen, die keine Admin-Zustimmung erfordern, werden als geringe Auswirkung eingestuft. Diese sind Berechtigungen, die für grundlegende Anmeldungen erforderlich sind, wie openid, profile, email, User.Read und offline_access. Wenn eine Organisation **Benutzerzustimmung für alle Apps erlaubt, kann ein Mitarbeiter einer App die Zustimmung erteilen, die obigen Informationen aus ihrem 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.
2 Arten von Illicit Consent Grant Angriffen
Unauthenticated: Von einem externen Konto eine Anwendung mit den Berechtigungen
User.Read
undUser.ReadBasic.All
erstellen, einen Benutzer phishen und du kannst auf Verzeichnisinformationen zugreifen.Dies erfordert, dass der gephishete Benutzer in der Lage ist, OAuth-Apps aus externen Umgebungen zu akzeptieren!
Authenticated: Nachdem ein Principal mit ausreichenden Privilegien kompromittiert wurde, eine Anwendung innerhalb des Kontos erstellen und einen privilegierten Benutzer phishen, der privilegierte OAuth-Berechtigungen akzeptieren kann.
In diesem Fall kannst du bereits auf die Informationen des Verzeichnisses zugreifen, sodass die Berechtigung
User.ReadBasic.All
nicht mehr interessant ist.Du bist wahrscheinlich an Berechtigungen interessiert, die ein Admin erteilen muss, da ein normaler Benutzer OAuth-Apps keine Berechtigungen erteilen kann, weshalb du nur diese Benutzer phishen musst (mehr dazu, welche Rollen/Berechtigungen dieses Privileg gewähren, später)
Überprüfen, ob Benutzer zur Zustimmung berechtigt sind
Der folgende PowerShell-Befehl wird verwendet, um die Zustimmungskonfiguration für Benutzer im Azure Active Directory (Azure AD) bezüglich ihrer Fähigkeit zur Zustimmung zu Anwendungen zu überprüfen:
Benutzerzustimmung deaktivieren: Diese Einstellung verbietet es Benutzern, Anwendungen Berechtigungen zu erteilen. Keine Benutzerzustimmung zu Anwendungen ist erlaubt.
Benutzer können Anwendungen von verifizierten Herausgebern oder Ihrer Organisation zustimmen, aber nur für Berechtigungen, die Sie auswählen: Diese Einstellung erlaubt allen Benutzern, nur Anwendungen zuzustimmen, die von einem verifizierten Herausgeber veröffentlicht wurden und Anwendungen, die in Ihrem eigenen Mandanten registriert sind. Es fügt eine Kontrollschicht hinzu, indem es nur für spezifische Berechtigungen Zustimmung erlaubt.
Benutzer können allen Anwendungen zustimmen: Diese Einstellung ist permissiver und erlaubt allen Benutzern, jeder Anwendung Berechtigungen zu erteilen, solange diese Berechtigungen keine administrative Zustimmung erfordern.
Benutzerdefinierte App-Zustimmungspolitik: Diese Einstellung zeigt an, dass eine benutzerdefinierte Richtlinie vorhanden ist, die auf spezifische organisatorische Anforderungen zugeschnitten werden kann und möglicherweise eine Kombination von Einschränkungen basierend auf dem App-Herausgeber, den Berechtigungen, die die App anfordert, und anderen Faktoren beinhaltet.
Verständnis des Illicit Consent Grant Angriffs
Bei einem Illicit Consent Grant Angriff täuschen Angreifer Endbenutzer dazu, einer bösartigen Anwendung, die bei Azure registriert ist, Berechtigungen zu erteilen. Dies geschieht, indem die Anwendung legitim erscheint, was dazu führt, dass Opfer unwissentlich auf eine "Akzeptieren"-Schaltfläche klicken. Infolgedessen stellt Azure AD ein Token für die Seite des Angreifers aus, das es ihnen ermöglicht, auf die Daten des Opfers zuzugreifen und diese zu manipulieren, wie z.B. E-Mails zu lesen oder zu senden und auf Dateien zuzugreifen, ohne ein organisatorisches Konto zu benötigen.
Überblick über den Angriffsablauf
Der Angriff umfasst mehrere Schritte, die auf ein generisches Unternehmen abzielen. So könnte er ablaufen:
Domainregistrierung und Anwendungs-Hosting: Der Angreifer registriert eine Domain, die einer vertrauenswürdigen Seite ähnelt, z.B. "safedomainlogin.com". Unter dieser Domain wird ein Subdomain erstellt (z.B. "companyname.safedomainlogin.com"), um eine Anwendung zu hosten, die Autorisierungscodes erfasst und Zugriffstoken anfordert.
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. Sie konfigurieren die Redirect-URL der Anwendung so, dass sie auf die Subdomain zeigt, 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, einmal vom Benutzer erteilt, ermöglichen es dem Angreifer, im Namen des Benutzers sensible Informationen zu extrahieren.Verteilen bösartiger Links: Der Angreifer erstellt einen Link, der die Client-ID der bösartigen Anwendung enthält, und teilt ihn mit den Zielbenutzern, um sie dazu zu bringen, die Zustimmung zu erteilen.
Verwendung von Tools für den Angriff
Der Angriff kann mit Tools wie 365-Stealer erleichtert werden.
Vorbereitung vor dem Angriff:
Wenn der Angreifer ein gewisses Maß an Zugriff auf einen Benutzer in der Opferorganisation hat, könnte er überprüfen, ob die Richtlinie der Organisation es dem Benutzer erlaubt, Anwendungen zu akzeptieren:
Um den Angriff auszuführen, müsste der Angreifer eine neue App in ihrem Azure Tenant (in App-Registrierungen) erstellen, konfiguriert mit den Berechtigungen:
User.ReadBasic.All
befindet sich in Microsoft Graph
unter Delegated permissions
. (Anwendungsberechtigungen benötigen immer eine zusätzliche Genehmigung).
User.ReadBasic.All
ist die Berechtigung, die es Ihnen ermöglicht, Informationen aller Benutzer in der Organisation zu lesen, wenn sie gewährt wird.Denken Sie daran, dass nur
GA
,ApplicationAdministrator
,CloudApplication
Administrator
und eine benutzerdefinierte Rolle, dieBerechtigung zum Gewähren von Berechtigungen an Anwendungen
enthält, eine tenantweite Zustimmung erteilen können. Sie sollten also einen Benutzer mit einer dieser Rollen phishen, wenn Sie möchten, dass er eine App genehmigt, die eine Admin-Zustimmung erfordert.
Sie könnten auch eine App über die CLI erstellen mit:
Schauen Sie sich https://www.alteredsecurity.com/post/introduction-to-365-stealer an, um zu erfahren, wie man es konfiguriert.
Beachten Sie, dass das erhaltene Access Token für den Graph Endpoint mit den Scopes: User.Read
und User.ReadBasic.All
(die angeforderten Berechtigungen) gilt. 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.
Post-Exploitation
Sobald Sie Zugriff auf den Benutzer haben, können Sie Dinge tun wie das Stehlen sensibler Dokumente und sogar das Hochladen von Dokumenten mit Hintertüren.
Referenzen
Last updated