窃取应用访问令牌

Sub-techniques (1)

ID	Name
T1528.001	多阶段低频令牌渗透

窃取应用访问令牌是指攻击者通过非法手段获取用于身份验证的API令牌，进而实施横向移动和数据窃取的攻击行为。这些访问令牌用于代表用户或服务进行授权的API请求，广泛应用于云和基于容器的应用程序以及软件即服务（SaaS）环境中。窃取应用访问令牌后，攻击者可以利用这些令牌的权限访问数据、执行操作，甚至进行权限提升和进一步的环境破坏。传统防御手段主要依赖令牌生命周期管理（如短期有效期）、权限最小化原则以及异常API调用监控。检测机制通常关注异常地理位置登录、高频次资源访问或非常规权限使用等特征。

为规避传统检测机制，攻击者发展出深度融入业务场景的令牌窃取技术，通过操作节奏控制，将恶意行为嵌入正常业务交互链条，着重解决攻击痕迹时空分散化问题。当前匿迹技术采用多阶段低频令牌渗透，通过长周期攻击链解构规避行为基线检测，突破传统基于单点异常的安全模型，通过深度适配目标环境的技术生态和行为模式，构建具备表面合法性的攻击路径。

ID: T1528

Sub-techniques: T1528.001

ⓘ

Tactic: 凭据获取

ⓘ

Platforms: Containers, IaaS, Identity Provider, Office Suite, SaaS

Contributors: Arun Seelagan, CISA; Jack Burns, HubSpot; Jeff Sakowicz, Microsoft Identity Developer Platform Services (IDPM Services); Mark Wee; Ram Pliskin, Microsoft Azure Security Center; Saisha Agrawal, Microsoft Threat Intelligent Center (MSTIC); Shailesh Tiwary (Indian Army); Suzy Schapperle - Microsoft Azure Red Team

Version: 1.4

Created: 04 September 2019

Last Modified: 14 October 2024

匿迹效应

效应类型	是否存在
特征伪装	✅
行为透明	❌
数据遮蔽	❌
时空释痕	✅

特征伪装

攻击者通过注册表面合规的OAuth应用，将恶意权限请求嵌入标准授权流程，使令牌获取过程呈现合法应用交互特征。利用容器元数据服务的标准API接口实施凭证窃取，使操作流量与正常系统管理行为特征高度一致，规避基于API调用模式的检测。

时空释痕

多阶段攻击将令牌窃取过程分散至数周甚至数月，单次操作频率低于常规检测阈值。通过全球云基础设施动态切换攻击源，利用不同时区的工作时段实施操作，破坏行为模式的时空关联性，使得防御系统难以通过集中行为分析来识别攻击者的行为模式。

Procedure Examples

ID	Name	Description
S0677	AADInternals	AADInternals can steal users’ access tokens via phishing emails containing malicious links.^[1]
G0007	APT28	APT28 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".^[2]
G0016	APT29	APT29 uses stolen tokens to access victim accounts, without needing a password.^[3]
S0683	Peirates	Peirates gathers Kubernetes service account tokens using a variety of techniques.^[4]

Mitigations

ID	Mitigation	Description
M1047	Audit	Administrators should audit all cloud and container accounts to ensure that they are necessary and that the permissions granted to them are appropriate. Additionally, 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.
M1021	Restrict Web-Based Content	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
M1018	User Account Management	Enforce role-based access control to limit accounts to the least privileges they require. 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. In Kubernetes applications, set "automountServiceAccountToken: false" in the YAML specification of pods that do not require access to service account tokens.^[5]
M1017	User Training	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.

Detection

ID Data Source Data Component Detects

ID	Data Source	Data Component	Detects
DS0026	Active Directory	Active Directory Object Modification	Monitor M365 Audit logs for the Operations Add app role assignment grant to user and/or Consent to application occurring against AzureActiveDirectory Workloads. Analytic 1 - Unusual app role assignments or consents to applications. `index=security sourcetype="WinEventLog:Security" EventCode=5136 OR (index=azuread sourcetype="azure:activity" operationName="Add member to role" OR operationName="Update application" OR operationName="Update servicePrincipal") OR(index=gsuite sourcetype="gsuite:admin" event_type="UPDATE_GROUP" OR event_type="UPDATE_USER") OR(index=o365 sourcetype="o365:management:activity" operation IN ("Add member to role", "Update user", "Update group"))`
DS0002	User Account	User Account Modification	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. Analytic 1 - Unauthorized app permissions or unusual activity patterns in app logs. `(index=security sourcetype="WinEventLog:Security" EventCode=4720 OR EventCode=4722 OR EventCode=4738) OR(index=azuread sourcetype="azure:activity" operationName IN ("Add member to role", "Update user", "Update group")) OR(index=gsuite sourcetype="gsuite:admin" event_type IN ("UPDATE_USER", "ADD_USER_TO_GROUP")) OR(index=o365 sourcetype="o365:management:activity" operation IN ("Add member to role", "Update user", "Update group"))`

DS0026

Active Directory

Active Directory Object Modification

Monitor M365 Audit logs for the Operations Add app role assignment grant to user and/or Consent to application occurring against AzureActiveDirectory Workloads.

Analytic 1 - Unusual app role assignments or consents to applications.

index=security sourcetype="WinEventLog:Security" EventCode=5136 OR (index=azuread sourcetype="azure:activity" operationName="Add member to role" OR operationName="Update application" OR operationName="Update servicePrincipal") OR(index=gsuite sourcetype="gsuite:admin" event_type="UPDATE_GROUP" OR event_type="UPDATE_USER") OR(index=o365 sourcetype="o365:management:activity" operation IN ("Add member to role", "Update user", "Update group"))

DS0002

User Account

User Account Modification

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.

Analytic 1 - Unauthorized app permissions or unusual activity patterns in app logs.

(index=security sourcetype="WinEventLog:Security" EventCode=4720 OR EventCode=4722 OR EventCode=4738) OR(index=azuread sourcetype="azure:activity" operationName IN ("Add member to role", "Update user", "Update group")) OR(index=gsuite sourcetype="gsuite:admin" event_type IN ("UPDATE_USER", "ADD_USER_TO_GROUP")) OR(index=o365 sourcetype="o365:management:activity" operation IN ("Add member to role", "Update user", "Update group"))