2026-10-15 11:06:18 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

AI 代理被用于攻击韩国金融机构，自动化能力正在压缩入侵周期

汇能云安全

2026年10月10日 10:15
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

10月10日，星期六，您好！中科汇能与您分享信息安全快讯：

AhsayCBS 备份平台被打穿：攻击者拿到的不只是服务器，还有恢复能力

BleepingComputer 报道，攻击者正在利用 AhsayCBS 备份管理平台中的两个漏洞入侵目标环境。CVE-2026-105133 可绕过认证，CVE-2026-105134 则可以进一步触发操作系统命令注入，Huntress 在 10 月 7 日观察到相关攻击活动，至少有 5 家组织被瞄准。攻击者进入系统后，不只是简单放一个挖矿程序，而是部署 JSP WebShell、开展主机侦察，并通过伪装成 Edge 更新服务的方式维持长期访问。这类事件真正危险的地方，在于备份平台处于企业恢复链条的核心位置。很多单位把备份系统当成 “出问题以后才用” 的设备，日常安全投入反而低于办公系统和生产系统。一旦攻击者控制备份管理平台，就可能继续接触恢复数据、管理凭据、快照和其他受保护主机，后续勒索的破坏范围会明显扩大。报告还指出，相关问题的版本影响情况并不简单，不能只根据安装包显示的版本号判断是否安全。厂商修复状态没有完全明确之前，建议立即限制 AhsayCBS 管理界面，只允许可信 IP 或 VPN 访问，并关闭不必要的公网暴露。安全团队要排查异常服务、JSP 文件、PowerShell 脚本、名为 Edge 更新服务的可疑进程和挖矿行为。确认主机被入侵后，不要只删除矿工，应从干净备份恢复，并同步轮换管理账号、API 密钥和远程连接凭据。

医疗设备没停摆，患者数据仍然可能被批量下载

医疗设备公司 iRhythm 披露，6 月发生的一起网络攻击导致至少 360000 人的个人信息被窃取。其中，德州涉及 298647 人，南卡罗来纳州涉及 69526 人，其他地区的影响范围仍可能继续确认。攻击者并没有直接破坏临床系统或心脏监测设备，而是通过社会工程手段进入第三方托管的业务应用，在 6 月 3 日至 8 日期间访问并下载数据，被涉及的信息包括姓名、地址、电话号码、患者账户号、设备序列号、保险编号、服务日期和出生日期。iRhythm 表示，事件没有造成医疗设备停运、生产中断或临床业务瘫痪，但这并不意味着风险较低。对患者来说，保险信息、出生日期和设备关联信息依然可能被用于精准诈骗、身份冒用或后续钓鱼，这起事件最值得企业反思的地方，是 “核心系统没有被攻破” 不能再作为安全结论。医疗机构的数据流通常跨越医院、设备厂商、云平台、外包服务商和接口供应商，一个权限范围看似有限的第三方账号，只要能够调用真实业务应用，就可能持续导出敏感数据。医疗机构应重新盘点所有供应商账号、API 密钥、远程支持权限和数据导出接口，落实多因素认证、最小权限、短期令牌、来源限制和调用审计。发现异常后，应立即吊销会话、轮换密钥，并核查同一供应商是否还接入其他系统。安全审计不能只盯着有没有停机，还要确认哪些数据被访问、被下载以及是否已经离开受控环境。

云平台遭勒索后，最先消失的可能是控制台和快照

日本 IDC Frontier 披露，IDCF Cloud 东日本一区在 10 月 7 日凌晨遭遇勒索软件攻击，导致网络和系统关闭，影响 495 家使用该服务的企业和地方政府。厂商随后隔离了受影响区域，并暂时关闭所有区域的管理控制台，等完成安全确认后再逐步恢复访问。攻击者在客户控制台留下的消息声称，已经加密 225 个数据库，涉及 3.6PB 数据，触及 239 台虚拟化主机、16000 个虚拟磁盘，并删除超过 55 万个快照。不过，这些数字属于攻击者声明，目前不能直接当作已经独立核实的损失。真正需要关注的是，云平台客户在事件期间同时失去了业务资源、管理入口和部分恢复能力。很多企业做云上备份时，只考虑 “数据有没有复制”，却忽略了备份是否与生产环境使用同一账号、同一控制面和同一权限体系，如果攻击者拿到云平台管理员权限，生产数据、快照、备份和恢复脚本可能被一并删除。即使云厂商最终能够恢复基础设施，客户也未必能立即恢复自己的业务状态。使用公有云的单位应确认备份是否跨账号、跨区域，并尽量采用不可变存储或隔离账号保存关键备份。管理密钥不能长期有效，也不能让应用账号拥有删除快照和修改恢复策略的权限。发生云平台安全事件后，恢复前要检查快照完整性、轮换访问密钥、重新验证镜像和虚拟机启动脚本，并要求云厂商提供入侵路径、日志留存和客户数据影响范围。云上业务也必须准备不依赖单一区域和单一控制台的应急方案。

攻击关键基础设施不一定从大漏洞开始，长期暴露的设备同样危险

美国联邦调查局称，已查封与中国关联的 Integrity Technology Group 运营的两套攻击平台 MicroScan 和 FishHub 所使用的 7 个域名。调查文件显示，MicroScan 被用于自动化扫描网络弱点，并结合感染 Mirai 的联网设备寻找目标；相关活动涉及电力公司、机场、天然气和电力企业以及大学网络，部分扫描之后出现了成功入侵。FishHub 则被用于定向钓鱼、投递后续恶意软件、远程控制受害网络和窃取文件。也就是说，这不是单纯的互联网测绘活动，而是一条从发现资产、寻找弱点到建立访问和外传数据的攻击链。对于能源、交通、教育等行业而言，真正的风险不只来自一台服务器是否被入侵，还来自边界系统能否继续向内部网络扩散。关键基础设施运营者应重新清点全部公网资产，包括旧设备、远程维护接口、VPN 网关、测试环境和长期无人维护的域名。关闭不必要的管理服务，修复外部系统，限制联网设备向互联网发起出站连接，并对扫描、钓鱼和远程工具行为设置告警。安全团队还要检查异常的端口探测、登录失败、管理账号新增、脚本投递和非业务文件外传记录。如果历史上曾出现相关域名或基础设施通信，也不能因为域名已经被查封就直接结束调查。攻击者可能更换控制节点，已经落地的后门和被盗凭据仍然有效。关键行业需要把资产暴露管理、身份安全和网络分区放在同一个防守框架里，而不是只等待厂商发布下一轮补丁。

GitHub 假仓库数量暴涨，AI 工具安装链正在变成新的投毒入口

FakeGit 活动重新扩大，BleepingComputer 披露，攻击者从 10 月 4 日起重新利用 GitHub 上的假仓库传播 SmartLoader，相关仓库数量达到 17610 个，并在 34 小时内新增超过 13000 个。研究人员抽样发现，97% 的仓库主要修改 README 文件，88% 的下载按钮指向包含恶意载荷的 ZIP 压缩包，至少 700 个账号看起来像正常开发者账号。这类活动的伪装方式非常直接：仓库名称、项目说明和下载按钮都尽量模仿真实工具，用户点击之后看到的是熟悉的安装步骤，实际下载的却是恶意程序。此前已经有一批假仓库伪装成 AI 技能或 MCP 服务器，说明开发者现在面对的不只是传统软件包投毒，还包括插件、技能、示例项目和命令行工具这些信任入口。企业应明确规定，AI 技能、MCP 服务、开发工具和依赖包只能从官方仓库或经过安全审核的来源安装。不能因为项目拥有大量星标、README 写得完整，或者账号看起来像开发者，就直接运行其中的下载命令。对外部脚本要先进行代码审查、哈希校验和沙箱测试，禁止在生产环境直接执行未经审核的安装程序。如果员工已经下载或运行可疑压缩包，应按潜在信息窃取事件处理。立即撤销 GitHub 会话和访问令牌，检查 SSH 密钥、云凭据、浏览器密码和本地配置文件，并核对是否有异常提交、仓库创建或凭据调用。高权限账号应改用通行密钥和最小权限，开发环境与生产环境之间也要保持清晰隔离。

Telegram Desktop 公开 PoC：一个外部链接可能牵出本地文件和账号会话

Cyber Security News 披露，Telegram Desktop 的 CVE-2026-107181 已经出现公开概念验证代码。漏洞存在于外部链接唤起已运行 Telegram 客户端时的本地进程通信处理，攻击者可以构造特殊链接，让客户端错误解析其中的内容，并调用原本用于内部发布流程的功能。在特定条件下，攻击者可能读取本地文件，并通过 Telegram 本身把文件发送到聊天中；如果进一步取得本地会话数据，还有可能造成账号接管。报告中的演示主要针对 Windows 上的 Telegram Desktop 6.9.3 至 7.2.8 版本，攻击链还依赖自动下载群文件、允许陌生人拉群以及未设置本地密码等条件。截至报道时，没有证据证明已经出现实际在野利用，因此不能把公开 PoC 等同于已经发生大规模攻击。Telegram 已在 7.2.9 版本中修复相关问题。用户不要因为漏洞需要点击一次链接，就把它当成普通低风险缺陷。很多人会在浏览器、邮件或办公软件里点击 “打开 Telegram” 的链接，浏览器弹出的应用启动提示并不代表目标链接可信。建议立即升级所有 Telegram Desktop 安装，启用本地密码，关闭自动下载和不必要的群组邀请。升级前遇到浏览器要求打开 Telegram 的提示时，不要直接确认。企业环境还应通过软件资产管理平台确认实际版本，而不是只看员工是否安装了最新安装包。怀疑已经受影响的设备，应结束其他活跃会话，检查异常文件发送记录，并重新登录重要账号。涉及敏感工作的终端，还应核查 Telegram 本地目录和系统启动项是否出现异常文件。

React Server Components 拒绝服务漏洞，业务鉴权挡不住请求解析消耗

React Server Components 披露的 CVE-2026-23870 属于高危拒绝服务漏洞，CVSS 评分为 7.5。攻击者向 Server Function 或 Server Action 端点发送特制 POST 请求，就可能让 React 在重建表单数据时反复扫描字段，消耗大量 CPU 并阻塞 Node.js 事件循环，最终导致正常请求超时、返回 503，甚至让负载均衡器把实例判定为不健康。受影响的是 React 19.0.0 至 19.0.5、19.1.0 至 19.1.6 和 19.2.0 至 19.2.5，对应修复版本为 19.0.6、19.1.7 和 19.2.6。Next.js 项目不能只看顶层框架版本，还要检查实际依赖树，因为受影响的 react-server-dom-webpack、react-server-dom-turbopack 或 react-server-dom-parcel 可能是通过间接依赖进入项目的。这个漏洞的麻烦在于，资源消耗发生在 Server Action 业务逻辑执行前。应用内部即使设置了严格鉴权，也不一定能阻止请求在解析阶段消耗大量 CPU，公网可访问的 Server Action 风险更高，但只要普通认证用户能够访问相关端点，也不能完全排除被滥用的可能。开发团队应升级 React Server Components 相关包，重新构建并部署全部环境，确保锁文件和实际生产镜像已经使用修复版本。网关层可以设置 POST 体大小、请求速率和处理超时限制，但这些只能降低冲击，不能替代升级。监控上要重点关注异常表单请求、CPU 飙升、请求队列堆积、实例频繁重启和健康检查失败。部署完成后，还要从外部测试 Server Action 端点是否仍然暴露在不必要的公网范围内。

AI 代理被用于攻击韩国金融机构，自动化能力正在压缩入侵周期

Security Affairs 转述 CrowdStrike 研究称，9 月底至 10 月初，攻击者借助名为 ARTEX 的 AI 渗透测试工具和多个大模型，针对韩国金融机构实施入侵并窃取数据。研究人员从攻击者暴露的目录中看到了 Claude Code 会话记录、工具配置和模型记忆文件，能够还原部分操作流程。目前没有确认具体攻击组织，也没有可靠公开的受害机构总数，因此报道中的推测不能被直接当作定论。但事件本身已经说明，AI 正在从辅助写脚本的工具，逐步被接入扫描、漏洞分析、横向操作和数据整理流程，过去需要人工反复执行的工作，可能被代理连续推进，攻击者处理多个目标的速度随之提升，金融机构尤其需要警惕这一变化。很多企业已经在内部部署 AI 编程助手、自动化运维工具和安全代理，但权限设计往往沿用了普通脚本的思路，没有充分考虑模型可能理解并组合多个工具调用。一旦代理拥有过大的网络出口、文件读写或命令执行权限，模型上下文泄露、提示注入或账号被盗都可能转化为真实操作。金融机构应把 AI 代理当作高权限自动化组件管理，限制其网络出口、文件访问和命令执行范围，禁止把生产密钥、客户数据和内部提示词直接写入会话记忆。安全团队要审计代理调用日志、异常扫描、批量读取和数据外传行为，并对公网管理面、移动办公系统和贷款业务接口重新核验访问控制。AI 工具能提高效率，但不能成为权限边界的替代品。

Chrome 桌面版发布安全更新，浏览器已经是企业身份入口

Google 在 10 月 6 日发布 Chrome 桌面稳定版更新，Windows 和 Mac 版本推进到 155.0.8059.39/.40，Linux 版本为 155.0.8059.39。官方公告列出了本轮安全修复，部分漏洞细节会在大多数用户完成更新后再逐步公开，以降低攻击者在补丁发布后的利用窗口。浏览器更新经常被企业当成普通办公软件维护，但现在的 Chrome 已经连接着企业身份认证、SaaS 系统、密码管理器、浏览器扩展和内部业务平台。一旦渲染、沙箱、扩展或授权边界出现缺陷，攻击者可能从恶意网页或钓鱼页面开始，进一步窃取会话、诱导安装扩展，甚至利用浏览器进程访问企业资源。建议企业通过资产管理平台确认实际运行版本，而不是只看安装包是否存在。对长期离线、固定版本、使用扩展较多或承担财务和管理工作的终端，应优先安排更新，并同步检查 Edge 等 Chromium 内核浏览器。更新后还要验证企业策略是否真正覆盖员工笔记本、VDI 和服务器桌面环境。安全团队可以将浏览器异常崩溃、陌生扩展、浏览器进程拉起脚本解释器、异常下载和更新后外联纳入监控。用户侧则要避免从搜索广告、弹窗或非官方页面安装浏览器组件。补丁不是一次性动作，浏览器版本、扩展清单和登录会话都应该成为终端安全持续盘点的一部分。

AWS 修复 AgentCore 输入校验问题，AI 代理不能只依赖模型来守权限

AWS 官方安全公告披露，Amazon Bedrock AgentCore harness 曾存在 CVE-2026-18830。问题出在 InvokeHarness 接口对输入内容校验不足：经过认证的用户如果在最后一条消息中直接提交工具调用内容，可能绕过模型调用和相关安全控制，直接执行该 harness 已经配置的工具。影响范围取决于 harness 本身配置的工具权限。没有配置工具的 harness 不会因此执行工具，工具集受限的 harness 也会限制攻击者能够完成的操作。AWS 表示，已经在托管服务端增加输入校验，拒绝相关请求，托管服务不需要客户自行部署补丁。这起事件的价值，不在于某个云产品出现了一个漏洞，而在于它再次说明：模型不是安全边界。企业如果把 “模型会不会同意” 当成唯一的权限控制，就可能让攻击者通过特殊输入绕过预期流程。真正的防护应当同时包括调用者身份、工具授权、服务端校验和审计记录。管理员应盘点每个 AgentCore harness 可以调用的工具，移除不必要的写入、删除、外发和管理权限，审计谁可以调用 InvokeHarness，并检查近期是否出现异常工具调用。自建代理或衍生 SDK 还要单独核对输入验证逻辑，不能因为托管服务已经修复，就默认本地代码也自动安全。对 AI 代理开放生产权限时，建议先从只读工具开始，逐步增加权限，并为高风险操作设置人工确认和独立审计。

信息来源：人民网国家计算机网络应急技术处理协调中心国家信息安全漏洞库今日头条 360威胁情报中心中科汇能GT攻防实验室安全牛 E安全安全客 NOSEC安全讯息平台火绒安全亚信安全奇安信威胁情报中心 MACFEESy mantec白帽汇安全研究院安全帮卡巴斯基安全内参安全学习那些事安全圈黑客新闻蚁景网安实验室 IT之家IT资讯黑客新闻国外天际友盟