盗取应用程序访问令牌

攻击者可以窃取用户应用程序访问令牌，作为获取凭据以访问远程系统和资源的一种方式。这可以通过社会工程学发生，通常需要用户采取行动才能授予访问权限。

应用程序访问令牌用于代表用户发出授权的API请求，并且通常用作在基于云的应用程序和软件即服务（SaaS）中访问资源的方式。[1] OAuth是一种普遍实施的框架，向用户发布令牌以访问系统。希望访问基于云的服务或受保护的API的应用程序可以通过各种授权协议使用OAuth 2.0获得访问权限。常用的示例序列是Microsoft的授权码授予流程。[2] [3] OAuth访问令牌使第三方应用程序能够以应用程序请求的方式与包含用户数据的资源进行交互，而无需获取用户凭据。

攻击者可以通过构建旨在使用目标用户的OAuth令牌被授予访问资源权限的恶意应用程序来利用OAuth授权。对手将需要在授权服务器上完成其应用程序的注册，例如，使用Azure门户，Visual Studio IDE，命令行界面，PowerShell或REST API调用的Microsoft Identity Platform。[4]然后，他们可以通过Spearphishing Link(T1192)将链接发送给目标用户，以诱使他们授予对应用程序的访问权限。授予OAuth访问令牌后，应用程序可以通过Application Access Token(T1527)获得对用户帐户功能的潜在长期访问。

已经看到针对Gmail，Microsoft Outlook和Yahoo Mail用户的对手。

标签

ID编号： T1528

策略： 凭证访问

平台： SaaS，Office 365，Azure AD

所需权限： user

数据源： Azure活动日志，OAuth审核日志

程序示例

名称	描述
APT28 (G0007)	APT28 (G0007) 使用了几种恶意应用程序来窃取用户的OAuth访问令牌，其中包括伪装为Gmail用户的“ Google Defender”，“ Google Email Protection”和“ Google Scanner”的应用程序。他们还针对雅虎用户提供了伪装为“交付服务”和“ McAfee电子邮件保护”的应用程序。

Name	Description
APT28 (G0007)	APT28 (G0007) has used several malicious applications to steal user OAuth access tokens including applications masquerading as "Google Defender" "Google Email Protection," and "Google Scanner" for Gmail users. They also targeted Yahoo users with applications masquerading as "Delivery Service" and "McAfee Email Protection". [7]

缓解措施

缓解	描述
审计 (M1047)	管理员应对所有OAuth应用程序及其获得的访问组织数据的权限进行审核。为了确定基准，应该在所有应用程序上广泛执行此操作，然后定期对新的或更新的应用程序进行审核。应调查可疑应用程序并将其删除。
限制基于Web的内容 (M1021)	管理员可以阻止最终用户同意OAuth应用程序，从而禁止用户通过OAuth 2.0对第三方应用程序进行授权，并对所有请求强制进行管理同意。他们还可以阻止最终用户对其用户进行应用程序注册，以降低风险。Cloud Access Security Broker也可以用于禁止应用程序。Azure在Azure管理门户中提供了一些企业策略设置，这些设置可能有助于：可以将“用户->用户设置->应用程序注册：用户可以注册应用程序”设置为“否”，以防止用户注册新应用程序。可以将“企业应用程序->用户设置->企业应用程序：用户可以同意代表他们访问公司数据的应用程序”设置为“否”，以防止用户同意允许第三方多租户应用程序
用户帐号管理(M1018)	Cloud Access Security Broker（CASB）可用于设置使用策略并管理云应用程序上的用户权限，以防止访问应用程序访问令牌。
用户培训(M1017)	需要对用户进行培训，以使其不授权他们不认识的第三方应用程序。用户应特别注意重定向URL：如果URL是与预期服务或SaaS应用程序相关的单词的拼写错误或混乱的单词序列，则该网站可能试图欺骗合法服务。用户还应该对他们授予应用程序的权限保持谨慎。例如，脱机访问和阅读电子邮件的访问应该引起更高的怀疑，因为攻击者可以利用SaaS API来发现凭据和其他敏感通信。

Mitigation	Description
Audit(M1047)	Administrators should perform an audit of all OAuth applications and the permissions they have been granted to access organizational data. This should be done extensively on all applications in order to establish a baseline, followed up on with periodic audits of new or updated applications. Suspicious applications should be investigated and removed.
Restrict Web-Based Content (M1021)	Administrators can block end-user consent to OAuth applications, disabling users from authorizing third-party apps through OAuth 2.0 and forcing administrative consent for all requests. They can also block end-user registration of applications by their users, to reduce risk. A Cloud Access Security Broker can also be used to ban applications.Azure offers a couple of enterprise policy settings in the Azure Management Portal that may help:"Users -> User settings -> App registrations: Users can register applications" can be set to "no" to prevent users from registering new applications. "Enterprise applications -> User settings -> Enterprise applications: Users can consent to apps accessing company data on their behalf" can be set to "no" to prevent users from consenting to allow third-party multi-tenant applications
User Account Management(M1018)	A Cloud Access Security Broker (CASB) can be used to set usage policies and manage user permissions on cloud applications to prevent access to application access tokens.
User Training(M1017)	Users need to be trained to not authorize third-party applications they don’t recognize. The user should pay particular attention to the redirect URL: if the URL is a misspelled or convoluted sequence of words related to an expected service or SaaS application, the website is likely trying to spoof a legitimate service. Users should also be cautious about the permissions they are granting to apps. For example, offline access and access to read emails should excite higher suspicions because adversaries can utilize SaaS APIs to discover credentials and other sensitive communications.

检测

管理员应设置监视以在满足策略标准时触发自动警报。例如，管理员可以使用Cloud Access Security Broker（CASB）创建“高严重性应用程序权限”策略，该策略在应用程序请求高严重性权限或向太多用户发送权限请求时生成警报。

安全分析人员可以使用其CASB，身份提供商或资源提供商（取决于平台）中提供的工具来寻找恶意应用。例如，他们可以筛选少数用户授权的应用，这些应用要求高风险权限，与应用目的不符的权限，或具有旧的“上次授权”字段的应用。可以使用显示应用程序已执行活动的活动日志来调查特定的应用程序，尽管某些活动可能会误记为用户正在执行。应用商店可能是进一步调查可疑应用的有用资源。

管理员可以设置各种日志，并利用审核工具来监视由于OAuth 2.0访问而可以执行的操作。例如，审核报告使管理员能够识别特权升级操作，例如角色创建或策略修改，这可以是在初次访问后执行的操作。

Administrators should set up monitoring to trigger automatic alerts when policy criteria are met. For example, using a Cloud Access Security Broker (CASB), admins can create a "High severity app permissions" policy that generates alerts if apps request high severity permissions or send permissions requests for too many users.

Security analysts can hunt for malicious apps using the tools available in their CASB, identity provider, or resource provider (depending on platform.) For example, they can filter for apps that are authorized by a small number of users, apps requesting high risk permissions, permissions incongruous with the app’s purpose, or apps with old "Last authorized" fields. A specific app can be investigated using an activity log displaying activities the app has performed, although some activities may be mis-logged as being performed by the user. App stores can be useful resources to further investigate suspicious apps.

Administrators can set up a variety of logs and leverage audit tools to monitor actions that can be conducted as a result of OAuth 2.0 access. For instance, audit reports enable admins to identify privilege escalation actions such as role creations or policy modifications, which could be actions performed after initial access.