Warum gewinnen Angreifer weiterhin mit Einwilligungs-Phishing?

Seit mindestens Februar 2025 hat Okta Threat Intelligence eine Erpressungskampagne verfolgt, bei der Angreifer Voice-basiertes Social Engineering, Anmeldedaten-Phishing und Gerät-Code-Phishing einsetzten, um auf Salesforce-Umgebungen zuzugreifen und Daten daraus zu exfiltrieren. 

Angreifer gaben sich in Telefongesprächen mit anvisierten Benutzern als technisches Support-Personal aus. Diese Benutzer wurden bei diesen Anrufen oft dazu verleitet, eine von einem Angreifer kontrollierte OAuth-Anwendung („Salesforce Data Loader“) zu autorisieren, um auf ihr Salesforce-Unternehmen zuzugreifen. Infolgedessen erhielt die Anwendung die Berechtigungen, die für den Zugriff auf Daten und deren Exfiltration im Benutzerkontext erforderlich waren.

Eine erste Kampagne von Anmeldedaten-Phishing-Angriffen im Februar 2025 zielte auf Dutzende von Unternehmen ab. Ab März 2025 begannen die Angreifer, Geräte-Code-Phishing in Angriffen zu verwenden, die Daten von Google, Workday und vielen anderen exfiltrierten. 

Eine Frage, die man sich stellen sollte, ist: Warum sind diese relativ einfachen Angriffe gegen mehrere Unternehmen mit gut ausgestatteten Sicherheitsprogrammen wirksam? 

Die Antwort liegt in zwei unrealistischen Erwartungen:

1. Es ist inakzeptabel, von den Benutzern zu erwarten, dass sie konsequent zwischen einer harmlosen und einer bösartigen OAuth-Anwendung unterscheiden. Bei diesen Angriffen wird ein Benutzer angewiesen, mit echten Sign-in- und Zustimmungsseiten von einer Trusted-Domain zu interagieren und erhält wenig Kontext, um die Anwendung, die Zugriff anfordert, zu überprüfen. Sicherheitsbewusstseinsprogramme können eine mildernde Rolle spielen, sollten jedoch nicht die primäre Kontrolle darstellen.
   

2. Für Sicherheitsadministratoren ist es komplex und ineffizient, Tausende von OAuth-Verbindungen zu Hunderten von Kernanwendungen Punkt-für-Punkt zu verwalten (d. h. allowlist) Tausende von OAuth-Verbindungen zu Hunderten von Kernanwendungen auf einer Punkt-zu-Punkt-Basis.
   
   Das interne Security-Team von Okta hat zum Beispiel Tausende von OAuth-Integrationen blockiert, die einen gewissen Zugriff auf eine unserer Hauptplattformen suchten. Das durchschnittliche Enterprise verfügt über mehr als 200 Kernanwendungen, von denen Dutzende den Anspruch haben, erweiterbar genug zu sein, um als „Plattform“ betrachtet zu werden.
   

Diese Komplexität wird zunehmen, da KI-Agenten Zugriff auf geschützte Ressourcen anfordern, um Aufgaben im Namen der Benutzer auszuführen. Agentic KI wird diese Autorisierungskrise letztendlich auf den Höhepunkt bringen: Unsere Branche hat kaum eine andere Wahl, als die App-zu-App-Autorisierung für eine agentische Welt zu überdenken.

Standardmäßig erlaubten die meisten Enterprise App-Ökosysteme den Benutzern historisch gesehen, Drittanbieteranwendungen den Zugriff auf Daten in ihrem Account zu gestatten. Microsoft hat angekündigt, dass es beabsichtigt, den Kurs für alle neuen Azure-Apps bis Ende August 2025 umzukehren, und Salesforce hat angekündigt, dass Benutzer ab Ende September 2025 nicht mehr zustimmen können, nicht installierte verbundene Apps zu autorisieren.

Die für das Security-Team verfügbaren Kontrollen, um Drittanbieter-Verbindungen auf die Positivliste zu setzen, sind stark fragmentiert. Unternehmen können die Aufgabe, die Reputation von OAuth-Apps zu bewerten, an Drittanbieter auslagern, aber dies skaliert bereits heute nicht gut und wird in einem agentischen Kontext unüberschaubar.

Um die aktuellen Probleme zu lösen und die agentische Zukunft zu sichern, müssen wir zunächst dieses grundlegende App-zu-App-Autorisierungsproblem angehen. 

Der logischste Ort, um dieses Problem zu lösen, ist die Ebene des Identity-Anbieters (Identity-Anbieter). Heute bestimmen die am Identity-Anbieter konfigurierten Richtlinien, welche Benutzer unter einem festgelegten Satz von Bedingungen auf welche Ressourcen zugreifen können. Okta Single Sign-On (SSO) kann verwendet werden, um die Anzahl der Anmeldedaten zu verringern, die sich ein Benutzer merken muss, sowie die Gesamtzahl der Sign-in-Herausforderungen, die er erfüllen muss. Es ergibt Sinn, die Autorisierung des Datenaustauschs zwischen denselben Anwendungen über dieselbe Richtlinien-Engine zu steuern. 

Okta hat Cross App Access als eine Möglichkeit vorgeschlagen, um die Sichtbarkeit und Kontrolle des App-Ökosystems für IT- und Security-Teams wiederherzustellen. Das Versprechen von Cross App Access besteht darin, die Sichtbarkeit und Kontrolle über App-zu-App- und Agent-zu-App-Verbindungen zu zentralisieren.

Auf branchenüblichen Standard-OAuth-Abläufen basierend, würde Cross App Access Administratoren das erste Mitspracherecht darüber geben, auf welche Daten Apps oder Agenten von einer Enterprise-Anwendung zugreifen können.

Zugriffsanfragen von einem nicht autorisierten Agenten oder einer nicht autorisierten Anwendung könnten anschließend beim Identity-Anbieter auditiert oder blockiert werden, anstatt in jeder einzelnen Anwendung oder durch die Verwendung von Sicherheitstools von Drittanbietern.

Und genau wie SSO hat die Zentralisierung von Autorisierungsentscheidungen beim Identity-Anbieter das Potenzial, die kognitive Belastung der Benutzer zu reduzieren. Wenn eine Integration zwischen zwei Anwendungen von Sicherheitsadministratoren in den Richtlinien vorab genehmigt wurde und ein Benutzer mit SSO bei beiden Anwendungen angemeldet ist, können Administratoren das Vertrauen gewinnen, die Gesamtzahl der Zustimmungsaufforderungen, mit denen ein Benutzer konfrontiert wird, zu reduzieren. 

Wenn die Branche Cross App Access einführt, können wir den Benutzern die Last abnehmen, selbst entscheiden zu müssen, ob eine bestimmte Anwendungsintegration legitim oder bösartig ist. Benutzer werden nur einer erlaubten Liste von Verbindungen mit einem vordefinierten Scoping zustimmen können und müssen in vielen Fällen keinen Zustimmungsbildschirm angezeigt bekommen.

Empfehlungen für ISVs

Wir empfehlen ISVs und Entwicklern, sich über die Integration von Cross App Access zu informieren und den Support für die neuen Standards vorzubereiten, die diesem zugrunde liegen.

Empfehlungen für CISOs

• Helfen Sie mit, das Bewusstsein für Cross App Access bei Ihrer Okta-Community und bei Enterprise-Software-Anbietern zu fördern.

• Registrieren Sie Benutzer für Phishing-resistente Authentifizierungsfaktoren wie Okta FastPass oder Passkeys und erzwingen Sie Phishing-Resistenz in der Richtlinie.

• Überprüfen Sie, welche Ihrer bestehenden Anwendungen App-to-App- oder Agent-to-App-Verbindungen über OAuth unterstützen. Erwägen Sie einen gestuften Ansatz für die Allowlist.

• Verschaffen Sie dem Security-Team über Identity Security Posture Management (ISPM)-Tools einen Überblick über die von Benutzern zugewiesenen Apps.

• Führen Sie Übungen zum Sicherheitsbewusstsein durch, die das Phishing von Zustimmungseingabeaufforderungen simulieren, um Benutzer über die Risiken der Genehmigung nicht autorisierter und unerwünschter App-Integrationen aufzuklären.

• Stellen Sie sicher, dass Ihr primärer Sicherheitskontakt bei Okta auf dem neuesten Stand ist, um Zugriff auf die neuesten Bedrohungshinweise von Okta Threat Intelligence zu erhalten. Bitte beachten Sie, dass der primäre Sicherheitskontakt jetzt andere Benutzer aus ihrem Unternehmen einladen kann, Dokumente anzusehen, ohne sie zum Kontaktdatensatz hinzufügen zu müssen. Die Funktion „Kollegen einladen“ finden Sie im User Profile, nachdem Sie sich bei okta-security.helptechsolucoes.com.brangemeldet haben.