企业官网建设流程全解析

• 网络安全
• 渗透测试
• 应用安全
• 安全与开源治理

PEASS-ng 的 winPEAS 在枚举 Windows 系统云凭据时，需要自行解密 Chrome 等客户端使用 AES-GCM 加密保存的令牌数据，这一能力正依赖其 3rdParty 目录中捆绑的 Bouncy Castle Crypto Package for C#。本文以该库自带 README（winPEAS/winPEASexe/winPEAS/3rdParty/BouncyCastle/README.md）为主体，结合仓库内完整的源码树与 winPEAS 的真实调用代码，说明这个加密库的定位、功能边界、许可约束，以及它在权限提升枚举场景下如何被实际使用，帮助读者理解并复用这一套加密能力。

Bouncy Castle C# 加密包是什么

Bouncy Castle Crypto Package for C# 是一套用 C# 实现的加密算法与协议库，由Legion of the Bouncy Castle（一个在澳大利亚注册的慈善机构）开发维护。它并非 PEASS-ng 团队自研，而是被 winPEAS 作为第三方依赖随源码一起打包进仓库，因此被放置在3rdParty目录中。

该库的核心价值在于两点：

• 提供基础密码学算法：包括对称加密、非对称加密、消息摘要、随机数生成等底层原语；
• 覆盖多种行业标准协议：除基础算法外，还提供CMS（Cryptographic Message Syntax）、TSP（Time Stamp Protocol）、X.509 证书生成，以及OpenPGP等多种标准的实现支持。

从 winPEAS 仓库中实际捆绑的源码树可以看到这套能力的组织方式。以 3rdParty/BouncyCastle 目录 为例，主要包含以下几个包：

其中digests目录下共收录了 30 余种摘要算法实现，包括 MD2/MD4/MD5、SHA-1/SHA-2 全系（Sha1Digest.cs、Sha224Digest.cs、Sha384Digest.cs、Sha512Digest.cs）、SHA-3 与 Keccak、SM3（国密）、Blake2、Skein、Whirlpool、Tiger、RIPEMD 系列以及 GOST 系列，覆盖了从传统到现代的各类哈希场景。

许可模型与合规要点

README 中明确说明了该库的许可与合规信息，这是在使用或二次分发时需要特别注意的部分：

• 主体许可：除特别注明外，本软件基于MIT X Consortium license分发，属于宽松型开源许可，允许在保留版权声明的前提下自由使用、修改与再分发；
• OpenPGP 库的特殊情况：OpenPGP 部分包含一个经过修改的 BZIP2 压缩库，该部分遵循Apache Software License, Version 2.0，因此在涉及 OpenPGP 相关代码时需同时遵守 Apache 2.0 的条款；
• FIPS 版本区分：README 特别强调，当前这份源码树并非 FIPS 版本的 API。FIPS（Federal Information Processing Standards）是面向美国联邦政府合规要求的一套经过认证的密码实现。若读者需要 FIPS 版本，需要直接联系 Bouncy Castle 官方（office@bouncycastle.org），而不能从本仓库获取。

项目协作与反馈渠道

作为开源项目，README 也介绍了参与方式，读者在遇到问题或希望贡献时可以参考：

• 邮件列表：项目维护两个订阅式邮件列表。订阅方式是在邮件正文中包含单词subscribe，退订则将正文中的subscribe替换为unsubscribe：
  • announce-crypto-csharp-request@bouncycastle.org：仅用于发布新版本公告，普通订阅者不能向其发帖；
  • dev-crypto-csharp-request@bouncycastle.org：用于讨论包开发相关事务，包括 bug、意见、功能增强请求以及使用或操作方面的问题。
  • 注意：需要先完成订阅才能向上述列表发送邮件。
• 直接反馈：如需直接向 Legion 成员提供反馈，可使用feedback-crypto@bouncycastle.org；
• Bug 报告与代码贡献：可以在 GitHub 仓库提交 issue，也接受基于该仓库的 pull request，但前提是所包含的任何代码都允许在 Bouncy Castle License 下分发。

从 NuGet 依赖到内置源码：winPEAS 的集成方式

winPEAS 与 Bouncy Castle 的集成是"双轨"的：既有 NuGet 程序集引用，也有随仓库内置的源码副本。

在 packages.config 第 11 行可以看到依赖声明：

<package id="Portable.BouncyCastle" version="1.9.0" targetFramework="net48" />

对应地在 winPEAS.csproj 中，第 120-121 行声明了程序集引用：

<Reference Include="BouncyCastle.Crypto, Version=1.9.0.0, Culture=neutral, PublicKeyToken=0e99375e54769942, processorArchitecture=MSIL"> <HintPath>..\packages\Portable.BouncyCastle.1.9.0\lib\net40\BouncyCastle.Crypto.dll</HintPath> </Reference>

同时，csproj 从第 912 行开始，将3rdParty\BouncyCastle\下的大量源码文件（如 asn1、crypto 等目录下的.cs文件）直接以Compile项纳入项目编译。这种"程序集引用 + 源码内置"并存的模式，可以理解为：源码树保留了库的完整实现，便于查阅与审计，而实际运行时通过 Portable.BouncyCastle 1.9.0 程序集提供加密能力。

实战：winPEAS 如何用 BouncyCastle 解密 Google Workspace 刷新令牌

BouncyCastle 在 winPEAS 中最有代表性的用途，出现在云凭据枚举模块中。winPEAS 会检查本机是否存在 Google Cloud Credential Provider for Windows（GCPW）加入的痕迹，并尝试解密 Chrome 为 Google Workspace 保存的刷新令牌（refresh token），其实现位于 Info/CloudInfo/GWorkspaceInfo.cs。

该文件第 8-10 行引入了三个 BouncyCastle 命名空间：

using Org.BouncyCastle.Crypto; using Org.BouncyCastle.Crypto.Parameters; using Org.BouncyCastle.Crypto.Modes;

解密流程全景

整个刷新令牌提取链路分为四步，核心步骤如下：

1. 定位数据源：从 Chrome 用户数据目录（LocalAppData\Google\Chrome\User Data）下的Default*与Profile*配置文件中寻找Web Data（SQLite 数据库）；
2. 提取主密钥：读取 Chrome 的Local State文件，从 JSON 的os_crypt.encrypted_key字段取回经 Base64 编码、带DPAPI前缀的加密密钥，去掉 5 字节前缀后用ProtectedData.Unprotect解密得到主密钥（见GetMasterKey，GWorkspaceInfo.cs 第 196-209 行）；
3. 查询令牌：通过内置的 System.Data.SQLite 打开Web Data，执行SELECT service, encrypted_token FROM token_service;取出加密令牌（见ExtractRefreshTokens，第 211-248 行）；
4. AES-GCM 解密：调用DecryptWithAESGCM完成最终解密（第 249-302 行）。

基于 BouncyCastle 的 AES-GCM 解密实现

DecryptWithAESGCM中定义了三个关键常量，与 Chrome 的加密格式一一对应：

int nonceLength = 12; // GCM 标准 nonce 长度 int macLength = 16; // GCM 认证标签（MAC）长度 string versionPrefix = "v10"; // Chrome 的 kEncryptionVersionPrefix

Chrome 存储的密文格式为v10 || nonce(12字节) || ciphertext || mac(16字节)，因此解密前需要依次校验版本前缀、切出 nonce、分离 MAC 与真正的密文。随后进入 BouncyCastle 调用：

GcmBlockCipher gcm = new GcmBlockCipher(new Org.BouncyCastle.Crypto.Engines.AesEngine()); AeadParameters parameters = new AeadParameters(new KeyParameter(key), macLength * 8, nonce); gcm.Init(true, parameters); byte[] plaintext = new byte[gcm.GetOutputSize(actualCiphertext.Length)]; int len = gcm.ProcessBytes(actualCiphertext, 0, actualCiphertext.Length, plaintext, 0); int len2 = gcm.DoFinal(plaintext, len);

这段代码的用法可以拆解为：

• AesEngine提供底层 AES 分组密码实现，对应 crypto/engines/AesEngine.cs；
• GcmBlockCipher将 AES 引擎包装为 GCM 认证加密模式，对应 crypto/modes/GcmBlockCipher.cs；
• AeadParameters接收KeyParameter（原始密钥）、认证标签位数（macLength * 8 = 128位）与 12 字节 nonce，对应 crypto/parameters/AeadParameters.cs；
• Init(true, parameters)中的true表示执行解密操作；
• ProcessBytes处理密文主体，DoFinal完成收尾并校验 GCM 认证标签，若 MAC 不匹配会抛出InvalidCipherTextException，该异常在方法末尾被转换为CryptographicException("Decryption failed due to MAC mismatch", ex)重新抛出。

整个解密之所以能成功，前提是"当前用户"的 DPAPI 主密钥可用——这也是该能力被纳入权限提升/凭据枚举的原因：一旦获得受害者用户上下文，winPEAS 即可还原其 Google Workspace 刷新令牌，进而可能访问其云账户资源。解密成功后，令牌以IsAttackVector = true标记输出（GWorkspaceInfo.cs 第 189 行），向审计者提示其敏感性与可利用性。

同一模式的横向复用：Azure 与 Google 云凭据枚举

类似的 BouncyCastle 引用模式也出现在其他云凭据枚举模块中。例如 Info/CloudInfo/AzureTokensInfo.cs 第 8-10 行同样引入了Org.BouncyCastle.Crypto、Org.BouncyCastle.Crypto.Parameters与Org.BouncyCastle.Crypto.Modes三个命名空间；GCDSInfo.cs 与 GPSInfo.cs 也保持相同的引用结构。可以推断，这些模块面向 Google 相关云服务凭据（如 GCDS、GPS）的加解密处理沿用了同一套 BouncyCastle API 风格，保持了解密逻辑的一致性与可维护性。

在自有项目中复用 BouncyCastle 的要点

结合本仓库的实践，若读者需要在自己开发的 .NET 项目中使用 BouncyCastle，可以总结出以下要点：

1. 引入方式二选一：生产项目建议通过 NuGet 引入Portable.BouncyCastle（winPEAS 使用的版本为 1.9.0，目标框架 net48），或在需要离线审计/单文件分发时仿照 winPEAS 将 3rdParty/BouncyCastle 源码直接纳入编译；
2. AES-GCM 标准用法：始终遵循AesEngine→GcmBlockCipher→AeadParameters的组合，并记得ProcessBytes与DoFinal搭配使用，DoFinal负责认证标签校验，密文被篡改时会抛出InvalidCipherTextException；
3. 注意许可叠加：非 OpenPGP 场景遵循 MIT X Consortium license，涉及 OpenPGP 的 BZIP2 部分需同时满足 Apache License 2.0；如需 FIPS 认证能力，应从官方获取 FIPS 版本而非使用本仓库的非 FIPS 源码树；
4. 版本一致性：若同时存在 NuGet 程序集引用与内置源码，注意两者 API 的版本对齐（winPEAS 以 1.9.0 为准），避免因版本差异导致解密参数（如 nonce 长度、MAC 长度）不匹配。

• 网络安全
• 渗透测试
• 应用安全
• 安全与开源治理