ShinyHunters为何不加密文件也能勒索企业？

原创

威胁猎人
威胁猎人

OSINT情报分析师

2026年10月23日 16:41
北京

去阅读

2025年8月，Google更新一篇威胁研究：当年6月，它自己的一个Salesforce实例，也遭遇了类似的攻击。

攻击者在访问被切断前取走了一部分数据。Google披露，涉及的主要是企业名称、联系方式等基础商业信息，大多原本就可公开获取。

这件事值得安全从业人员多看一眼。这类攻击可以不依赖Salesforce漏洞：冒充IT支持打电话，让员工批准一个应用，再通过获准的接口把数据导走。

这里没有必须先出现的加密进程，也没有必须先瘫痪的服务器。对企业来说，麻烦可能发生在一次看起来很正常的登录之后。

ShinyHunters相关活动，把这种风险反复带到了台前。它让企业面对一个比“备份能不能恢复”更难回答的问题：数据还在自己手里，但别人已经复制走了一份，该怎么办？

从早期出售失窃数据库，到如今围绕企业数据实施勒索，ShinyHunters相关活动不断利用新的入口。有些攻击者盯上的，正是企业为提高效率而建立的访问和授权流程。这些流程背后，连着最集中的那批业务数据。

一通电话能让员工交出什么

先看Google在2025年披露的UNC6040活动。攻击者冒充IT支持，诱导员工在Salesforce中批准由攻击者控制的连接应用。授权完成后，应用便能查询和导出相关数据。Google观察到的这些案例依赖对用户的操纵，而非Salesforce自身漏洞。

把产品名称暂时放到一边，问题就很熟悉了。

员工有一项工作要完成，眼前出现了一个自称来解决问题的人。对方要他做的，未必是把密码发到聊天窗口，也可能只是进入一个页面，完成一次连接或授权。

如果培训一直停留在“不要告诉别人密码”，员工遇到应用授权时，可能根本不会把它当成同一类风险。毕竟，密码没有说出去，认证也确实由自己完成了。

可授权处理的是另一件事：这个应用能代表你做什么。

一个人有资格登录CRM，不代表他应该有权让任意应用持续读取客户数据。登录认证和应用授权之间，隔着一道容易被忽略的权限边界。

到了2026年1月，Mandiant观察到的相关活动又把仿冒企业登录站点与电话结合起来，窃取SSO凭据和MFA验证码，部分攻击还登记了攻击者自己的认证设备。研究人员将这些活动分为多个威胁簇追踪，没有把它们简单看成同一批人。

统一登录给员工省掉了反复输密码的麻烦，也让一个身份能够接触更多系统。攻击者一旦取得这个身份，接下来值得看的就不只是登录页面，而是它后面连着的邮箱、网盘、CRM和协作平台。

对国内企业，这件事完全可以拿现有流程来检验。一个员工接到“升级认证”的电话后，能不能自行增加设备？业务人员能不能批准具有广泛数据权限的新应用？服务台凭什么确认申请重置账号的人确实是本人？

这些问题应当有能执行的答案。只让员工多一分警惕，却允许一次未经复核的操作放出大范围权限，出了事很难全归结为“安全意识不足”。

ShinyHunters威胁画像

一份几年前泄露的密码为什么还值钱

电话只是入口之一。2024年的Snowflake客户数据窃取活动，展示了另一种更省事的办法。

Mandiant调查的相关事件，都能追溯到失窃的客户凭据。调查没有发现证据表明，这些未授权访问源自Snowflake企业环境本身被攻破。攻击者主要使用此前由信息窃取木马盗走的账号密码，其中一些已经泄露多年，却仍然有效。

在相关受影响环境里，账号没有配置MFA，客户实例又缺少限制访问来源的网络允许列表。旧凭据便重新变成了进入数据库的通行条件。

这类事件最刺眼的地方，是时间。

终端上的一次失窃，可能早就过去了；项目可能已经结束，负责的人可能换了岗位，外包人员也可能离了场。但只要访问权限还在，攻击者拿到的就不只是“历史资料”。

数据集中到云上之后，一个账号能接触多少信息，值得重新算一遍。能够查询自己负责的业务，与能够导出整张客户表，是两种完全不同的能力。把两者都写成“只读账号”，很容易低估风险。

Ticketmaster和Santander相关数据被挂上地下论坛时，品牌、样本和报价一起出现在售卖帖中。对发帖者来说，知名企业的名字有助于吸引买家，也能给当事企业制造压力。

Ticketmaster数据售卖帖

Santander数据售卖帖

安全团队看这些截图，不能只记住哪个品牌又被挂出来。更实际的工作，是核对自己企业的那批旧账号：它们还有没有使用人，权限是谁批准的，项目结束后由谁回收，最近一次实际访问是什么时候（这才是网络安全人员的责任和担当，而不是一天到晚营销号发这个泄露了、那个勒索了，跟tm五毛党一样，做营销、博眼球、骗订阅费、糊弄领导、胡造经费................）。

如果凭据来自信息窃取木马，还要回到终端检查。电脑没有处置干净，就让用户在原设备上改密码，新凭据仍可能再次暴露。终端团队说“查杀完成”，身份团队说“密码已改”，并不自动意味着云端访问也已经恢复安全。

Truist与Authy相关地下论坛帖文

Airmeet数据售卖帖

密码改了那个应用可能还在取数据

有些访问甚至不需要再次使用员工密码。

2025年8月，Google披露UNC6395利用与Salesloft Drift相关的失窃OAuth令牌，访问多个Salesforce客户实例并导出数据。调查还发现，攻击者会在导出的内容里寻找AWS密钥、密码及Snowflake相关令牌，继续寻找其他入口。

OAuth令牌为什么重要？

企业批准一个应用接入业务系统后，需要一种机制，让它在获准范围内工作，而不必每次都找员工输入密码。令牌承担的就是这类访问凭据的作用。

员工可能早已忘记自己批准过什么，应用却仍按当时得到的权限运行。一次授权可以很快完成，清理它却需要有人记得它还存在。

这就解释了为什么供应商发来安全通知后，只确认本公司的服务器有没有中毒，可能会查错方向。真正需要核对的是：这家供应商连着哪些系统，使用哪个账号，持有什么权限，令牌有没有泄露，相关访问是否已经被终止。

Google在Drift事件的更新中，也把排查范围扩展到其他集成，建议客户检查相关连接、撤销并轮换凭据，调查连接系统。

对于本来就持有数据权限的应用，“改密码”不能被默认理解为“全部访问已切断”。会话、访问令牌、刷新令牌和API密钥怎样失效，需要按具体平台验证。

还有一个更让运维人员头疼的细节：业务数据本身也可能藏着下一把钥匙。

客服工单里临时发过的密码，聊天附件里保存的配置文件，客户排障时提交的连接信息，都可能让一次CRM泄露继续扩大。因此，客户数据的敏感程度，不能只按姓名、电话这些固定字段来判断。

国内团队可以先做一件不花哨的事：找出仍然持有高权限的第三方集成，确认每个应用都有负责人，知道它能读取什么，也知道出了事从哪里撤销。

如果这份清单要等到勒索信来了之后才开始建，最忙的那几个小时，就会花在四处寻找“当初是谁接的这个应用”上。

盯住身份之后别把老业务系统忘了

讲到这里，很容易形成另一个误会：只要守住账号，ShinyHunters相关威胁就管住了。

针对Oracle PeopleSoft的漏洞利用活动，已经把企业软件本身带进了这条攻击链。CVE-2026-35273涉及PeopleSoft PeopleTools，可在无需认证的情况下远程利用，成功后可能造成远程代码执行。Oracle列出的受影响版本包括8.61和8.62，并要求客户优先采取措施并更新。

同一套数据勒索生意，可以通过不同方式拿到原料。能用失窃账号就用账号，有机会滥用应用令牌就用令牌，存在可利用的软件漏洞，也不能指望攻击者主动绕开。

对使用这类系统的高校、大型集团和服务商，检查需要落到实际组件：部署在哪里，谁负责维护，哪些管理功能对外可达，修复是否真正生效。

CVE-2026-35273漏洞信息

漏洞修好了，还应回答修复前发生过什么。日志里有没有异常访问，服务器上有没有可疑文件，有没有新增账号或其他访问方式。补丁解决的是漏洞，既往入侵是否已经留下后果，需要另行调查。

这也是资产台账不能只服务于发通知的原因。一封“请尽快自查”的邮件发出去以后，应该能跟到一个具体的人、一套具体的系统，以及一个经过验证的结果。

勒索信上的名字也可能是生意的一部分

ShinyHunters的另一个麻烦，是这个名字本身。

Google分别追踪了Snowflake相关活动的UNC5537、Salesforce语音钓鱼的UNC6040，以及部分后续勒索活动的UNC6240。这些编号不能直接画成等号。

企业收到一封署着ShinyHunters的邮件，不能因此就认定发件人亲手完成了此前入侵。名字能增加威慑，却不能替调查人员证明身份。

截至2026年10月，我们的网空威胁情报系统共记录199条相关帖文，其中114条带有美国归属信息。同一机构可能对应多条记录，还有些帖子并不指向单一受害者，帖文数与受害机构数因此是两种口径。

ShinyHunters相关帖文监测统计

Rey与Aegis相关的渠道变化，也反映出这个名字背后的不稳定。在相关频道中，Aegis先后给出了彼此矛盾的创始人和领导权声明。熟悉的渠道仍在发声，已不足以说明它始终由同一批操作者控制。

Rey相关活动时间线

Aegis关于组织身份的不同自述

对地下市场来说，一个反复出现的名字有自己的价值。它可能让买家更愿意看帖子，也可能让受害者更快相信威胁。判断一封勒索信时，注意力应该尽快从落款回到对方究竟掌握了什么。

FBI在2026年5月的警示中指出，攻击者可能用真实或夸大的信息持有声明施压，并向当事人及其家属发送威胁信息。威胁需要认真处置，具体的数据范围仍要核实。

样本是否属于本企业，记录是什么时间产生的，有没有此前未泄露的内容，字段和业务能否对应，日志又能否解释它的流出路径？这些问题比对方自称是哪位“负责人”更急。

也别让多次转述制造出确定感。几家网站引用同一份帖子，仍然只有一个消息源。帖子上写了多少条记录，也不会因为截图被转发得足够多，就变成调查确认的数字。

收到一张IOC清单调查才刚开始

关联调查中积累的网络地址、联系标识和文件哈希，可以用来回溯历史活动。使用时要先弄清楚：这条记录出现在什么时间，与什么事件有关，本地有没有对应证据？

关联文件的SHA-256哈希

相关网络基础设施指标

相关联系账号与身份标识

地址会换，联系账号会换，数据也可能被重新打包出售。若检测只等着名单里的某个值出现，就容易漏掉换了外壳的同一种行为。

可以把视线移回本企业的一条业务链：某个账号刚完成恢复，接着新增认证设备，又批准了新应用，随后开始批量读取过去很少接触的数据。

其中任何一步，都可能有正常解释。把时间、身份、应用和导出对象放在一起，才有机会看出这个解释是否站得住。

这也比单设一个“大文件下载阈值”更接近实际问题。月末报表可能很大，正常备份也可能很大。要判断的，是谁在通过什么应用访问哪些数据，这种访问与他的工作是否相符。

相关攻击活动的MITRE ATT&CK技术映射

不妨做一次很小的演练：假设业务负责人报告，一个陌生应用正在读取客户资料。

平台管理员能不能找到授权记录，安全人员能不能看见导出行为，业务部门能不能判断字段的敏感程度？如果需要立刻暂停，究竟谁有权限操作？

演练不必等全套平台建齐再做。现在做不出来的步骤，往往就是事件发生后最容易耗掉时间的地方。

最后要查清的是数据已经走到了哪里

数据勒索与加密恢复有一个处置上的差别：即使企业始终能打开自己的文件，也可能已经失去了对副本的控制。

备份仍然重要，但恢复成功不能被当成数据泄露已经解决。应急预案需要单独回答，怎样停止后续读取，怎样查清外流范围，以及怎样验证攻击者已不能继续访问。

发现异常后，应同步开展止损和证据保全。按平台能力处理受影响身份的会话、应用授权和密钥，复核新增认证设备；同时保存关键日志和原始通信记录。不要为了等完整调查而放任导出继续，也不要在清理过程中把线索一起删除。

接下来，要让调查结果能够被业务部门理解。

“存在异常API调用”只是起点。涉及哪些业务对象，覆盖什么时间，包含哪些字段，是否混有能进入其他系统的凭据，现有证据分别能确认到哪一步，都应尽量说清楚。暂时未知的部分，也不能直接写成没有发生。

如果入口涉及供应商，就要追到具体连接。对方修复了哪个问题，撤销了哪些凭据，能提供哪些日志，本企业的连接是否也需要处理？“供应商已经修复”和“我们的访问风险已经消除”之间，还需要一次验证。

最后，不要用一张关闭的工单代替验证结果。旧令牌是否失效，异常应用是否清掉，正常业务是否恢复，临时收紧的权限是否又被随手放回去，系统负责人和安全人员最好一起确认。

ShinyHunters相关案例看下来，最值得带回公司的，未必是又一串团伙别名。

是那个几年没清理过的账号，是那个仍能导出客户数据的应用，是那个所有人都以为“供应商在管”的连接。它们平时不显眼，出了事却会把几个部门同时拉进会议室。

下一次例行检查，可以先找出企业里能导出最多业务数据的那个身份。确认谁在用它，它授权过什么应用，再实际验证一次：出现异常时，能不能及时停止访问。

不要等到勒索信到了，才开始问这份权限究竟归谁管！！！