黑客服务器裸奔泄露内幕:Aurora 勒索团伙用 Cursor AI 做攻击规划,完整还原从入侵到洗钱全链路
原创 威胁情报中心 2026-09-01 14:36 北京

Aurora 勒索软件"联盟成员"的全套底牌被看光了:攻击工具、Shell 历史、AI 聊天记录、加密器本体,一应俱全。
勒索软件深度调查
黑客服务器裸奔泄露内幕
Aurora 勒索团伙用 Cursor AI 做攻击规划,完整还原从入侵到洗钱全链路
Aurora 勒索软件"联盟成员"的全套底牌被看光了:攻击工具、Shell 历史、AI 聊天记录、加密器本体,一应俱全。
· 勒索软件 · 供应链追踪 · 2026-09-01
黑客也有粗心的时候。一名 Aurora 勒索软件的俄语操作者,把自己的整个 Linux 主目录毫无鉴权地挂在了公网 8888 端口上——攻击工具、Shell 历史、AI 聊天记录、加密器本体,一应俱全。安全公司 CloudSEK 与链上分析机构 TRM Labs 顺着这扇敞开的窗户,完成了一次罕见的"勒索软件运营全景直播"。
01 史上罕见的"内部视角"
2026 年 8 月 27 日,CloudSEK 旗下威胁研究团队 TRIAD 发布了"Caught in 4K"系列的首份报告。报告的素材来源颇为戏剧性:一个配置错误的开放目录(open directory),实际上是某名 Aurora 勒索软件联盟成员(affiliate)自己的操作机主目录,文件列表在 8888 端口上无需任何认证即可访问。
这个目录里有什么?按受害组织整齐归档的攻击成果、还"新鲜"的 Kerberos 票据与凭据材料、SAM 和 LSA 注册表转储、组策略导出、BloodHound 采集数据、操作者本人的 Shell 历史、Cursor(AI 编程助手)的完整聊天记录,以及 Aurora 加密器本体——勒索信和谈判用的 Tor 洋葱地址就硬编码在二进制文件里。

图 | 攻击者主机 8888 端口的开放目录列表,操作机主目录一览无余(图源:CloudSEK TRIAD)
基于这份带时间戳的完整记录,CloudSEK 还原了该操作者 2026 年 4 月至 7 月间 的活动全貌:
攻击了分布在 9 个国家的 20 余家组织;
在其中 17 家 取得了域级或交互式访问权限;
其中 4 名受害者 此后出现在了 Aurora 的公开数据泄露站点上;
从加密器中恢复出的密钥,让研究人员得以旁观一场已经结束的赎金谈判;
与 TRM Labs 合作完成链上追踪,发现该笔赎金与至少另一名 Aurora 受害者的付款经由同一套洗钱基础设施汇合。
02 流水线式的攻击手册:每一步都"标准化"
如果说这份目录最直观的感受是什么,那就是——重复。同样的工具序列、同样的输出文件命名规范,每一次入侵都像流水线上的同一个工序。

图 | Aurora 联盟成员攻击链全流程(据 CloudSEK 报告攻击手法整理)
1. 基础设施:永远不亲自露面
所有面向受害者的动作都经由租用的 SOCKS 代理跳板转发,主要是德国和美国的 VPS。操作者自己的基础设施从未直接触碰过任何受害者网络。
2. 枚举:NetExec 打头阵
通过 NetExec 进行 LDAP 与 SMB 探测、抓取密码策略、执行 ASREPRoasting 和 Kerberoasting。在其最深的一次入侵中,枚举范围覆盖了多台主机和数个域控制器。

图 | 操作者 Shell 历史:proxychains4 包裹的 NetExec LDAP 枚举命令(图源:CloudSEK TRIAD)
3. 提权:三条固定路线,按目标选用
定制版 noPac 链:机器账户重命名 → 获取 TGT → S4U2self,非公开 PoC 原版,而是自己改写过的脚本;
ADCS 证书服务滥用:覆盖 ESC1(证书模板配置错误,可铸造域管证书)、ESC6、ESC8 三类经典 misconfiguration,其中 ESC6 有一次因操作者自身 DNS 故障而未得手;
NTLM 中继:通过 PetitPotam、PrinterBug、DFSCoerce 三种手法强制域控机器账户回连认证,中继到目标完成提权,工具集中还包括一个等效于 DCSync 的中继变体。
4. 数据外泄:PowerShell + 7-Zip
用 PowerShell 驱动 7-Zip 把数据打成 50GB 一个的分卷包,暂存后拖走。
5. 横向与后渗透
evil-winrm、chisel、proxychains 负责横向移动和隧道;BloodHound 负责域内路径分析;Metasploit 承担 C2(包括 MS17-010 模块——在一台遗留主机上,永恒之蓝仍被直接用来创建账户)。此外,操作者还维护着一个私有 GitLab 仓库,存放自研的 NetExec 模块,包括一个针对七种浏览器的凭据窃取模块和一个专门的 ESXi 主机发现模块,全部用俄语撰写文档。
03 加密器解剖:一门冷门语言,两个平台,一套源码
勒索软件用 Go 写早已不新鲜,Rust 近年也逐渐流行,但 Aurora 选择了 Zig——一门尚未发布 1.0 版本的年轻系统级语言。这在勒索软件领域相当罕见。
Zig 的吸引力与 Go 类似:单文件静态编译、一套源码树交叉编译到多个操作系统、没有垃圾回收和运行时开销。但它没有 Go 那样的"前科"——公开恶意软件语料库中 Zig 样本远少于 Go 和 Rust,可用于训练检测签名的样本也就更少。不过 CloudSEK 也指出,这种"罕见"是双刃剑:一个如此不寻常的二进制反而更容易被精确指纹识别,因为它太显眼了。
两个加密器变体——Windows 版 sap.exe 和 Linux/ESXi 版 encrypt.out——出自同一套 Zig 代码库,只是编译目标不同。Windows 版二进制里甚至还残留着 Linux 版的用法示例,这是跨平台共用源码树留下的"彩蛋"。

图 | Aurora 加密器内置的命令行参数帮助(图源:CloudSEK TRIAD)
完整的命令行参数体现了高度的工程化:

图 | Aurora 加密器双平台执行逻辑(据 CloudSEK 报告与 Gambit Security 逆向分析整理)
参数 | 功能 |
| -path <文件夹> | 只加密指定目录(默认全盘) |
| -percent | 只加密每个文件的 0–100%(默认按文件大小自动决定比例,速度优先) |
| -f | 跳过超过指定大小的文件 |
| -threads / -scanners | 控制工作/扫描线程数(默认两倍核心数) |
| -noparallel | 关闭单文件多线程加密 |
| -esxi | ESXi 专用模式:只加密虚拟机相关文件(vmdk、vmx、vmsd、vmsn、nvram、vmem、vswp、log),并明确跳过 ESXi 系统卷 |
| -extensions <列表> | 仅 Windows:限定加密的文件扩展名 |
| -allowfolders <列表> | 仅 Linux:把默认跳过的系统目录(如 tmp、var)重新纳入加密范围 |
Windows 变体的反恢复设计是一个四连环:先启用备份特权,然后调用系统命令删除所有卷影副本并压缩卷影存储,再直接改注册表禁用系统还原,最后检查 Hyper-V 管理服务是否在运行。

图 | Windows 版四连环反恢复逻辑的反编译代码(图源:CloudSEK TRIAD)
Linux/ESXi 变体则更有"想法":
加密开始前,枚举宿主机上所有正在运行的虚拟机并逐一强制杀掉(据 Gambit Security 对同一样本的独立分析,具体调用 esxcli vm process list 收集 World ID,再以 esxcli vm process kill --type=force 终结虚拟机,从而释放虚拟磁盘文件锁);
勒索信不落盘成文件,而是写进 ESXi 宿主机的 SSH 登录横幅——任何管理员 SSH 登录时,先看到的是赎金通知;
内置一个"熵值看门狗":生成密钥材料前检查内核随机数池的余量,若熵耗尽则记录告警——这种"自我意识"在勒索软件工具中相当少见;
加密算法方面,Gambit Security 的逆向分析显示该样本使用 ChaCha20 原地加密文件内容,每个会话密钥由内嵌的 RSA-4096 公钥保护。

图 | 勒索信写入 sshd-banner 并重启 SSH 服务的反编译代码(图源:CloudSEK TRIAD)

图 | ESXi 模式枚举并强制终止虚拟机的反编译代码(图源:CloudSEK TRIAD)
04 当勒索黑客开始用 AI 做"作战参谋"
这可能是整份报告中最值得行业警醒的部分。
在行动的最后几周,Shell 历史显示操作者开始密集使用 Cursor(一款智能体编程助手)来起草和推演攻击序列,包括一份完全用俄语写成的 ADCS 利用方案。回收到的会话记录显示,这不是偶尔试水的尝鲜,而是围绕多个受害目标持续、高频的来回交互。

图 | 操作者与 Cursor 的俄语会话记录(图源:CloudSEK TRIAD)
Gambit Security 针对同一基础设施的独立研究提供了更多细节:操作者使用的是 Cursor Agent(底层运行 Claude Sonnet 模型),在 2026 年 4 月 8 日至 5 月 21 日期间辅助其对约 10 个目标进行实操利用。典型模式是:操作者向 Agent 提供凭据或既有内网通道,然后下达任务——配置 VPN 客户端与 proxychains、用 Nmap/NetExec 扫描、采集 BloodHound 数据、尝试 NTLM 中继、用 Certipy 做证书攻击等。Agent 首次尝试大多失败,随后自行修正命令和脚本,部分任务最终成功。
值得注意的是,操作者还给 Agent 设定了可复用的"行动纪律":不做 DCSync、不造成账户锁定、不在域内创建计算机对象——显然是为了降低动静、保住访问通道。
AI 在这里扮演的不是"自主黑客",而是放大器:一名懂得流程的操作者,借助它把每个环节的试错成本大幅压低。

图 | 操作者 × Cursor Agent 的 AI 辅助攻击闭环(据 CloudSEK 与 Gambit Security 报告整理)
05 跟着赎金走:链上的分赃与洗钱
从加密器中恢复出的密钥,让 CloudSEK 得以查看一场已结束的赎金谈判记录(CloudSEK 承诺永不公开该受害者身份)。谈判遵循 Aurora 的一贯套路:开价、以公开泄露为期限施压、付款后冷淡收尾。最终以和解告终——操作者提供的收款钱包在分析时余额为 7 BTC,这一体量更像是多名受害者赎金的累积,而非单笔付款。

图 | Aurora 谈判面板:泄露倒计时、BTC 收款地址与「不再回复」威胁(图源:CloudSEK TRIAD)
与 TRM Labs 合作的链上分析揭示了一个更大的图景:
TRM 对 Aurora 整体链上足迹的独立分析确认了 2 笔确凿的受害者付款 和 2 笔高度疑似来自不同受害者的付款,全部流经同一套洗钱基础设施(置信度评级:中高);
每笔付款起初各有路径、各自拆分,但多条路径在下游的共享归集节点重新汇合,再流向出金环节——这是一张洗钱网络,而非单一链条;
分成比例不固定:RaaS 模式通常默认联盟成员与幕后运营方之间有固定分账,但实测比例分别为 35/65、21/79、46/54、40/60,无一重复。这与 CloudSEK 通过人工情报(HUMINT)渠道独立获知的情况吻合——联盟成员的分成是按个案谈判的,与赎金规模、受害者营收等因素挂钩。链上数据与人工情报两个独立来源得出了同一结论;
分账后的资金在下游出现"混池"现象:看似属于运营方和联盟方的份额汇入同一个下游集群,这意味着要么初始拆分并非干净的两方划分,要么双方收益在出金前被有意归拢;
全部资金流中,两个主导归集集群承担了几乎所有分支的汇聚,再经数层中转流向少数最终出金点。唯一例外是一笔走"剥离链"(peeling chain)的付款:逐跳削去小额、直线奔向出金,全程不经过那两个枢纽。

图 | 四笔已追踪付款的运营方/联盟方分账比例,无一固定(图源:TRM Labs,经 CloudSEK 报告发布)

图 | 付款路径对比:归集路径 vs 独立「剥离链」(图源:TRM Labs,经 CloudSEK 报告发布)

图 | Aurora 洗钱网络全景:两个主导归集集群与左侧独立剥离链(图源:TRM Labs,经 CloudSEK 报告发布)
一个值得注意的比例:大约只有五分之一的确认受害者最终出现在公开泄露站点上。结合钱包余额与链上规模,Aurora 的真实侵害面很可能远大于泄露站点所展示的数字。
06 归因:一个讲俄语的职业联盟成员
CloudSEK 以高置信度作出三点判断:
1俄语操作者。所有操作者亲自产出的工件——Cursor 攻击计划、模块文档、会话笔记——均为俄语原生撰写,非机翻腔、非上游工具自带文本。
2是联盟成员,不是访问经纪人(access broker)。证据链没有止步于"访问权可售"的节点:凭据窃取、域控沦陷、数据外泄、加密器部署、赎金到账,全程由同一人操刀;加密器就放在操作者自己的目录里待命,而非转交给下家。旁证是时间线:从记录中的初始访问到泄露站点挂名,间隔最短仅约两周、最长不过两个月——这是"入侵即勒索"的作业节奏,不是囤货待沽的经纪人模式。
3刻意回避独联体(CIS)目标。三个月的目标清单、扫描记录和成功日志中,未出现任何一个 CIS 分配的 IP 段或 CIS 国家域名,无一例外;人工情报来源也印证了这一点。受害者以美国为最大头,行业上制造业占比最高,其次是食品农业、医药化工分销和专业咨询服务——典型的机会主义打法,有什么访问权就打什么。

图 | 四名已公开受害者从初始访问到泄露挂名的时间线(图源:CloudSEK TRIAD)

图 | 受害组织行业分布,2026 年 4–7 月(图源:CloudSEK TRIAD)

图 | 受害组织国家分布,美国占比最高(图源:CloudSEK TRIAD)
07 防御启示
报告给出的缓解建议可归纳为七条主线:
1封堵中继与投毒面 —— 禁用 LLMNR 和 NBT-NS,启用 SMB 签名与 EPA(扩展保护认证),将 WinRM 限制到指定管理主机,彻底关闭 SMBv1——尤其在域控上
2审计 ADCS —— 逐一排查证书模板的 ESC1/ESC6/ESC8 类错误配置,存在 ENROLLEE_SUPPLIES_SUBJECT 标志的一律移除或强制 CA 管理员审批,开启证书申请与签发事件审计
3怀疑域沦陷时 —— krbtgt 账户密码重置两次、间隔一个完整复制周期;对生命周期或有效期超出域策略的 Kerberos 票据告警
4收缩 SPN 暴露面 —— 清点所有持有 SPN 的账户,把 SPN 从特权账户(尤其是内置 Administrator)上移除;服务账号尽量迁移到 gMSA,其余强制使用长而复杂的口令
5把浏览器凭据当一等目标 —— 启用凭据存储加密,监控对浏览器配置目录的批量或脚本化访问
6隔离备份基础设施 —— Veeam 等平台使用独立凭据、独立网段,与生产 AD 隔离——备份系统失陷是加密事件临近的先行指标,而非次要问题
7淘汰或隔离 EOL 系统 —— 该操作者反复利用的正是可通过空会话 SMBv1 访问、无签名的老旧主机
此外,针对 ESXi 环境,"修改 sshd_config + 写入 sshd-banner + 重启 SSH 服务"这一组合行为具有极高特异性,可直接作为检测规则落地(见附录三)。
08 附录一:MITRE ATT&CK 技术映射
战术 | 技术 ID | 技术名称 | 对应行为 |
资源开发 | T1588.007 | Obtain Capabilities: AI | 使用 Cursor Agent 辅助制定攻击计划、执行利用任务 |
初始访问 | T1078 | Valid Accounts | 使用 SSL-VPN 等有效凭据进入受害网络 |
执行 | T1059.001 | PowerShell | PowerShell 驱动 7-Zip 打包外泄数据 |
凭据访问 | T1558.003 | Kerberoasting | 对 SPN 账户请求服务票据并离线爆破 |
凭据访问 | T1558.004 | AS-REP Roasting | 针对免预认证账户获取可离线破解的票据 |
凭据访问 | T1558.001 | Golden Ticket | 提取 krbtgt 哈希(食品/农业受害者案例) |
凭据访问 | T1003.002 | SAM | SAM 注册表转储 |
凭据访问 | T1003.004 | LSA Secrets | LSA 转储 |
凭据访问 | T1003.006 | DCSync | 含 DCSync 等效能力的 NTLM 中继变体 |
凭据访问 | T1555.003 | 浏览器凭据 | 自研 NetExec 模块窃取七种浏览器凭据 |
凭据访问 | T1110.003 | Password Spraying | Kerbrute 等口令猜测/喷射 |
凭据访问 | T1187 | Forced Authentication | PetitPotam / PrinterBug / DFSCoerce 强制认证回连 |
凭据访问 | T1557.001 | LLMNR/NBT-NS Poisoning | NTLM 中继提权 |
权限提升 | T1068 | Exploitation for Privilege Escalation | 定制 noPac 链(机器账户重命名 → TGT → S4U2self) |
权限提升 | T1649 | Steal or Forge Authentication Certificates | ADCS ESC1/ESC6/ESC8 滥用,铸造域管证书 |
发现 | T1087.002 | Account Discovery | NetExec LDAP 枚举 |
发现 | T1069.002 | Permission Groups Discovery | 域组枚举、BloodHound 路径分析 |
发现 | T1018 | Remote System Discovery | 内网主机发现(含自研 ESXi 发现模块) |
发现 | T1135 | Network Share Discovery | SMB 共享枚举 |
发现 | T1201 | Password Policy Discovery | 抓取域密码策略 |
收集 | T1560.001 | Archive via Utility | 7-Zip 按 50GB 分卷打包 |
横向移动 | T1021.001 | Remote Desktop Protocol | 交互式 RDP 会话 |
横向移动 | T1021.002 | SMB/Windows Admin Shares | SMB 横向移动 |
横向移动 | T1021.006 | Windows Remote Management | evil-winrm 会话 |
横向移动 | T1210 | Exploitation of Remote Services | MS17-010(永恒之蓝)攻击遗留主机 |
横向移动 | T1570 | Lateral Tool Transfer | scp 推送加密器至暂存主机 |
命令与控制 | T1090 | Proxy | 租用 SOCKS 跳板(德国/美国 VPS)、proxychains |
命令与控制 | T1572 | Protocol Tunneling | chisel 隧道 |
命令与控制 | T1105 | Ingress Tool Transfer | 从公开 Cloudflare R2 存储桶拉取加密器 |
命令与控制 | T1071 | Application Layer Protocol | Metasploit C2 通信 |
影响 | T1486 | Data Encrypted for Impact | Aurora 加密器加密文件 |
影响 | T1489 | Service Stop | ESXi 模式下强制终止运行中的虚拟机 |
影响 | T1490 | Inhibit System Recovery | 删除卷影副本、压缩卷影存储、注册表禁用系统还原 |
09 附录二:失陷指标(IOCs)
类型 | 值 | 说明 |
洋葱地址 | ijexszhscln27nl263lmcd7tx3jttkhm4wjhd4e3y6r4csdbfyeprvid.onion | Aurora 受害者谈判站点(内嵌于加密器) |
SHA-256 | eb0aab1e892d7e09e2c7bcf1d21fd83c1743ed9196b3efac6c78482fb0d99207 | sap.exe(Windows 加密器) |
SHA-256 | a4af136d159a8eb96b54924fa80355ca52874913301300f55af7d67ae97edcfe | encrypt.out(Linux/ESXi 加密器,139 KB ELF) |
文件名 | !!!README!!!DO_NOT_DELETE.txt | 勒索信文件名 |
IPv4 | 172.86.113.245 | 操作者 VPS |
IPv4 | 172.86.90.75 | 操作者 VPS |
IPv4 | 144.172.116.150 | 操作者 VPS |
IPv4 | 104.194.134.167 | 操作者 VPS(SOCKS 中继) |
IPv4 | 89.106.83.49 | 租用的 SOCKS 跳板 |
IPv4 | 23.234.108.48 | 租用的 SOCKS 跳板 |
IPv4:端口 | 167.88.167.37:50167 | C2 出口检查 |
IPv4:端口 | 45.61.148.166:21056 | 租用的 SOCKS 跳板 |
补充(来自 Gambit Security 的独立披露):加密器下载地址位于公开 Cloudflare R2 存储桶(pub-c057b7d0b24944a29e381ce9ea22a2f1.r2.dev);Aurora 明网泄露站点域名 exposedrecords.io;另有一批中置信度的 SOCKS 代理 IP 及疑似第二个活动集群的 C2 与 S3 外泄节点,详见其参考链接原文。
10 附录三:Sigma 检测规则
ESXi SSH 横幅勒索信投递检测:
title: Aurora Locker - ESXi SSH Banner Ransom Note Delivery
status: experimental
description: |
Detects the Aurora locker's ESXi ransom-note delivery mechanism: rather than dropping a note
file, it appends a custom banner directive to sshd_config, writes the note text into a file
named sshd-banner, and restarts the SSH service so the note appears on every login attempt.
logsource:
product: linux
service: auditd
detection:
selection_config:
CommandLine|contains: '/etc/ssh/sshd_config'
selection_banner_file:
CommandLine|contains: 'sshd-banner'
selection_restart:
CommandLine|contains|all: ['init.d', 'SSH', 'restart']
condition: all of selection_*
falsepositives:
- Rare; would require an administrator independently naming a custom banner file "sshd-banner"
while also editing sshd_config and restarting SSH in the same sequence
level: critical
11 参考链接