RatHat Android 恶意软件使用 AI，但 ADB 持久化才是更大的威胁

RatHat Android 恶意软件引入了 AI 引导的屏幕控制，但其更深层的威胁来自一套旨在抵御移除操作的三部分架构。安全研究人员在分析其自动化导航、凭证窃取和异常持久化机制后，于 2026 年 9 月 16 日披露了该恶意软件。据报道，RatHat 将 Android 无障碍功能访问、本地无线调试，以及两个在主要恶意应用之外运行的原生代理结合起来。

AI 组件帮助 RatHat 解读不断变化的界面，而非完全依赖固定指令。这让操作者能以更灵活的方式定位按钮、读取标签并操控受感染设备。不过，AI 并不会提供初始访问权限。受害者仍需从 Google Play 以外安装 Android 软件包，并授予启动攻击所需的权限。

更重要的变化在于，RatHat 试图在可见应用消失后继续保持控制。包括 PromptSpy 在内的早期 AI 辅助恶意软件，展示了语言模型如何导航不同厂商的界面。据报道，RatHat 将这种适应性与 Shell 级访问、凭证窃取覆盖层、键盘记录和持久化网络隧道相结合。

RatHat Android 恶意软件将 AI 与持久化控制结合

RatHat 将恶意 Android 应用转化为更广泛控制系统的入口，而该系统可在应用本身消失后继续存在。

Zimperium 的 zLabs 团队在研究通过短信钓鱼、恶意广告、钓鱼页面及第三方论坛传播的多阶段感染链后披露了 RatHat。这些渠道会将用户引向恶意 APK 文件，即绕过常规 Play Store 流程安装的 Android 应用软件包。

恶意应用首先会请求无障碍功能权限。Android 无障碍服务旨在帮助用户与设备交互，但也可能暴露界面内容并支持自动化输入。恶意软件操作者经常滥用这些能力读取屏幕、点击按钮和批准敏感操作。

据报道，RatHat 利用该访问权限启用开发者选项和无线调试，随后提取建立本地 Android Debug Bridge 连接所需的六位配对码。ADB 是 Android 用于开发、测试和设备管理的合法命令接口。

根据详细的 RatHat 分析，这一过程可让嵌入式 Go 代理无需外部计算机便获得 Shell 级执行能力。该代理以具有迷惑性的库名称 liblocal-service.so 存储。

该代理可执行命令、获取电池管理豁免、收集输入并支持持久化。Zimperium 表示，它还可检查恶意应用是否仍被安装，并在必要时恢复该应用。如果代理组件消失，应用同样可以恢复该代理。

名为 libmedia_codec.so 的第二个原生组件充当 Fast Reverse Proxy 客户端。它在手机上的本地服务与攻击者基础设施之间建立隧道。该路径为操作者提供的访问能力，并不完全依赖应用原始的命令通道。

RatHat 可展示仿冒银行、支付和加密货币应用的 HTML 覆盖层。覆盖层会将欺诈界面置于合法应用之上，诱导用户将凭证输入攻击者控制的字段。

研究人员还发现了拦截短信、通知和一次性密码的功能。该恶意软件能够记录文本变化、检查浏览器地址栏、截取屏幕并收集已安装应用列表。

据报道，其原生代理还会监控底层触摸输入。这项功能可帮助根据用户操作还原屏幕点击、PIN 码、密码和解锁图案。

这些能力意味着 AI 子系统只是威胁的一部分。RatHat 利用 AI 提升导航适应性，而 ADB 访问和原生代理则提供了持久运行的基础。

AI 导航引擎省去了代价高昂的人工步骤

RatHat 的 AI 之所以重要，是因为它能将不断变化的 Android 屏幕转化为结构化导航决策，无需操作者持续输入。

传统移动自动化高度依赖可预测的布局、资源标识符或精心编写的指令。当设备厂商更改菜单、翻译标签或重新设计系统对话框时，这种方法就会变得不可靠。

在 Google Pixel 上有效的指令，可能会在 Samsung、Oppo 或 Xiaomi 设备上失效。即使是屏幕尺寸、软件版本和无障碍结构方面的常规差异，也可能破坏固定的操作序列。

RatHat 通过将当前无障碍功能树序列化为 XML 来解决这一问题。这棵树描述可见界面元素、文本标签、元素类型及屏幕位置。恶意软件会将该结构化快照发送给 Zimperium 所称的一款热门生成式 AI 助手。

研究人员并未确认该服务、模型、账户或托管安排。因此，在没有更多证据的情况下，不应将 RatHat 描述为使用任何特定商业模型。

据报道，AI 组件会回答有针对性的界面问题。它可以返回指定元素中心点的坐标、确定元素显示的文本，或提供诸如 SCROLL_DOWN 的指令。

这是一个范围有限但实用的角色。该模型并不会自主构思攻击，也不会授予新的 Android 权限。它充当操作者目标与设备当前屏幕之间的界面解释器。

这种区分很重要，因为对自主恶意软件的耸动描述可能掩盖底层机制。RatHat 仍依赖社会工程学、危险权限、调试访问、恶意原生代码和攻击者控制的基础设施。

不过，其 AI 层确实可以减少人工投入。操作者无需监看每一块受感染屏幕，也不必为每种界面变体维护独立的自动化脚本。模型可以将实时界面数据转化为下一步操作。

BleepingComputer 的 AI 导航报告称，这种适应性使 RatHat 有别于完全基于静态脚本的自动化方式，也为远程操作者提供了另一种无需持续人工交互的导航手段。

该技术与早先发现的 PromptSpy 类似。该恶意软件会将屏幕状态数据发送给 Google Gemini，并接收将自身固定在设备最近使用应用界面中的指令。不同 Android 厂商的固定行为存在差异，因此这是一个适合模型引导导航的问题。

在早期研究发布时，ESET 尚未在其遥测数据中观察到 PromptSpy，因此其实际传播范围仍不确定。RatHat 将这一概念扩展为更全面的架构，但其流行程度同样尚未披露。

这一演进值得关注。生成式 AI 正从攻击开发辅助工具，进入部分恶意软件的执行循环。其直接优势并非超人般的推理能力，而是对界面差异的容忍度。

持久化而非 AI 带来了更棘手的安全问题

RatHat 的核心矛盾在于适应性与遏制能力：应用启动入侵，独立代理则试图维持入侵。

Android 的应用沙箱通常会将应用与敏感系统功能以及其他应用相互隔离。据报道，RatHat 利用本地 ADB 配对，将部分操作移至拥有更广泛命令访问能力的 Shell 级环境。

这并不意味着该恶意软件获得了无限制的 Root 权限。Shell 访问与 Root 访问不同。不过，ADB Shell 仍可执行传统应用无法执行的操作，并支持持久化命令执行。

RatHat 的 Go 代理会在设备的回环接口上暴露 HTTP 服务。反向代理组件随后可通过攻击者控制的隧道，使该内部服务能够被外部访问。这种安排将远程访问与恶意应用的可见界面分离开来。

由此形成的设计包含三个协作要素。Android 应用负责获取权限并协调活动；Go 代理执行命令并管理持久化；代理则维持通往本地服务的外部路径。

如果受害者仅移除应用，另一个组件据称可以重新安装它。如果原生代理停止运行，应用可以恢复该代理。这种相互恢复机制比单一持久化技巧更令人担忧。

RatHat 还会干扰常规移除操作。研究人员称，它会监视 Android 的卸载确认界面、取消操作，并在界面上显示伪造的 Google Play 错误信息。

类似的防移除行为早于 RatHat 出现。Android 恶意软件长期以来一直滥用无障碍服务点击导航按钮或遮盖安全控制。RatHat 将这一常见技术与独立的 Shell 访问通道结合起来。

该恶意软件的反分析防御又增加了一层复杂性。研究人员发现了容器篡改、异常 ZIP 属性、加密字符串、无效 DEX 伪指令，以及针对分析工具的运行时检查。

据报道，其 Android 清单文件大小为 61MB，其中 99% 由两种未记录的分块类型构成。Android 运行时会跳过这些分块，而一些分析工具在处理它们时可能失败或耗尽资源。

清单炸弹不会直接窃取凭证或控制手机。其目的是拖慢自动化检查，并使软件包更难分类。这种延迟可在特征和指标传播前，为攻击活动争取更多时间。

RatHat 还会检查调试器、重新打包、模拟器、Root 痕迹、Frida 和 Xposed。这些工具在恶意软件分析环境中很常见。检测到它们后，恶意代码可以改变行为，或在受检环境下停止运行。

这种组合架构会给仅关注应用文件的防御者带来压力。移除 APK、匹配已知哈希值或封锁一个命令服务器，未必能清除所有仍在活动的组件。

行为信号因此变得更重要。安全团队可以关注可疑的无障碍功能授权、意外的无线调试活动、本地 ADB 配对、异常原生守护进程和持久化反向隧道。

这并不意味着特征检测失去价值。已知的软件包哈希、域名、证书和网络指标仍然有用。RatHat 表明，这些信号需要运行时和设备状态监控的支持。

银行应用面对的是界面层面的对手

RatHat 攻击的是用户与金融应用之间的可信交互，而不只是应用内部存储的数据。

银行应用可以加密本地数据库并保护服务器通信，但恶意软件仍可能监视用户屏幕。如果恶意无障碍服务能够读取界面内容或注入触摸操作，应用层保护将面临另一类问题。

据报道，RatHat 会在目标银行和加密货币应用上方展示伪造的 HTML 界面。受害者可能会认为登录提示来自真实服务，却将信息输入恶意覆盖层。

该恶意软件随后可拦截包含验证码的短信或通知内容。它还能够收集输入的文本并监控浏览器地址，为操作者提供围绕所窃取凭证的上下文信息。

Android 已针对这些技术加入防御措施。Android 15 限制了屏幕共享期间以及通知监听服务对部分一次性密码的暴露。Android 16 则引入了一种机制，使开发者能够将敏感界面元素标记出来。

accessibilityDataSensitive 设置可阻止未经验证的 Accessibility 服务读取或与受保护视图交互。Google 的 Android 16 guidance 建议将其用于密码、财务信息及其他敏感字段。

开发者还可使用 Play Integrity 环境信号。app access verdict 可表明是否有其他应用获得了能够截取屏幕、显示覆盖层或控制设备的权限。

这些防御措施提高了 RatHat 的运作成本，但并未消除问题。防护效果取决于 Android 版本、设备配置、开发者采用情况，以及恶意应用是否已建立另一条控制通道。

Accessibility 也带来了艰难的平台权衡。Android 必须支持能够读取界面内容并代用户执行操作的合法辅助软件。封锁所有自动化交互会损害这些必不可少的工具。

Google 会审核通过 Play 分发的 Accessibility 工具，并警告其可能被用于欺骗性用途。其 Play Protect guidance 指出，可疑服务可能请求完全控制设备，并访问个人或财务信息。

据报道，RatHat 通过 Google Play 之外下载 APK 的方式进入设备。这降低了官方商店中的直接风险，但用户仍可通过浏览器、消息、论坛和第三方市场侧载应用。

Google 在 2026 年 3 月报告称，侧载来源中出现恶意软件的频率是 Google Play 的 90 倍以上。该公司正在扩大开发者验证范围，部分地区的安装要求计划于 2026 年 9 月 30 日开始实施。

这一时间节点使 RatHat 与平台针对恶意分发的更广泛应对措施并行出现。开发者验证可提升 Play 之外安装软件的可追责性，尽管高级安装路径仍将保留。

金融机构同样需要采取行动。高风险操作不应完全依赖于在可能已被攻陷的手机上显示或输入的信息。

交易确认可纳入服务器端风险评分、可信设备历史、行为变化，以及针对新添加收款人的限额。若设备完整性或应用访问权限信号显示风险升高，银行也可对会话发起额外验证。

对于企业团队而言，移动设备应获得与笔记本电脑同等深度的事件响应处置。一部存有身份验证应用、工作消息、云端会话和银行访问权限的手机，可能成为进入多个系统的跳板。

RatHat 的影响范围和归属仍不明确

该恶意软件的能力已有详尽记录，但其受害者数量、活动规模和操作者身份仍未得到确认。

Zimperium 将 RatHat 与疑似来自中国的行为者联系起来。公开证据包括恶意软件中发现的中文提示文本，以及已观察到的活动基础设施。

语言并不能构成决定性的归属证据。恶意软件开发者可能复用代码、植入误导性线索、跨境协作，或将工具出售给无关的操作者。现有公开报道并未指明具体组织或政府支持者。

公开研究也未提供已确认的感染数量。它没有列出受影响国家、被针对的银行、活动持续时间，或活跃命令服务器的数量。

这些缺失的信息限制了对即时风险暴露的判断。RatHat 可能支持一场高度定向的活动、一项仍在发展的犯罪服务，或是研究人员仅部分观察到的更大规模行动。

身份不明的 AI 服务带来了另一项不确定性。调查人员尚未公开说明恶意软件如何向该助手进行身份验证、发送请求的频率，或在连接失败时会发生什么。

基于云端的 AI 请求可能产生可被检测到的网络活动。服务提供商也可暂停滥用账户、过滤可疑提示，或配合调查。攻击者可能通过轮换账户、使用代理服务或转向本地托管模型来应对。

模型可靠性同样值得审视。当 XML 数据不完整、标签含义模糊，或屏幕出现意外对话框时，界面自动化可能失效。一次错误点击就可能暴露恶意软件、中断攻击，或使操作者失去访问权限。

这些限制并未消除威胁。它们表明，AI 辅助恶意软件仍依赖基础设施、凭证、网络连接和精心设计的回退逻辑。

此前的 PromptSpy 案例提供了有益参考。其模型辅助功能只处理了一项狭窄的持久化任务，而独立的 VNC 模块则实现远程控制。研究人员无法确认其样本代表的是活跃攻击活动还是概念验证。

RatHat 看起来在运作层面更为完整。其传播渠道、凭证覆盖层、命令系统、原生服务和隧道组件构成了一条连贯的攻击链。

不过，技术完整性并不等同于大规模部署。读者不应将每一项已记录能力都视作其已影响大量人群的证据。

Zimperium 还销售移动安全产品，并表示其产品能够检测 RatHat。这一商业背景并不会使技术发现失效，但独立复现仍然很有价值。

来自 The Hacker News 的第二份技术报道，基于 Zimperium 的披露印证了这一架构。它并非使用独立样本进行的独立恶意软件分析。

当前最有力的结论更为有限：研究人员分析了一种恶意软件，它将 AI 引导的界面解读、成熟的 Android 接管技术，以及异常持久的基于 ADB 的架构结合在一起。

三项信号将显示 RatHat 是否改变移动恶意软件格局

下一项检验在于，RatHat 的技术是否会扩散到这一已报道家族之外，并迫使防御者、金融应用和 Android 作出可衡量的改变。

第一项信号是独立的活动证据。更多研究人员应寻找匹配的样本、命令基础设施、签名证书、投递页面，以及客户遥测数据中的感染情况。

已确认的受害者地理分布将有助于明确 RatHat 是否针对特定银行或地区。样本数量的增长将表明其处于活跃开发或分发状态，而非一次孤立的技术实验。

如果缺乏广泛的遥测证据，那么 RatHat 构成即时全球性浪潮的说法将被削弱。这不会抹去其架构层面的教训，但会改变紧迫程度。

第二项信号是本地 ADB 持久化链的复用。恶意软件作者经常复制被证明可靠的技术，尤其是在公开研究披露了足以启发模仿的实现细节时。

防御者应关注是否有新家族启用 Wireless Debugging、恢复配对代码、部署 shell 层代理，并在应用被移除后保留访问权限。若这类做法被反复采用，这一机制的重要性将超过 RatHat 这个名称本身。

Android 和设备制造商可通过收紧 Accessibility、Developer Options、无线配对和后台 shell 进程之间的转换环节来应对。更明确的用户警告也可揭示这些操作的可疑组合。

第三项信号是运行时 AI 是否会超越界面查找。报道称，RatHat 会向模型询问坐标、可见文本和导航指令。未来样本可能利用模型对金融界面分类、调整欺诈提示，或基于更广泛目标选择操作。

这种发展将强化在恶意软件调查中监控 AI 服务流量的必要性。它也将促使模型提供商在不阻碍合法 Accessibility 和测试工作流的前提下识别自动化滥用。

如果 AI 仍仅限于少数脆弱的导航任务，RatHat 将更像是一次渐进式自动化升级。若多个恶意软件家族采用决策循环，防御者将面对跨设备更具变化性的行为。

用户无需等待这些信号，也可降低当前风险。避免安装通过未经请求的消息、广告或陌生下载页面提供的 APK 文件。对于与辅助功能无关的应用发出的意外 Accessibility 请求，应将其视为严重警告。

保持 Play Protect 启用，并允许其扫描陌生应用。在怀疑设备已被攻陷时，检查已启用的 Accessibility 服务、通知访问权限、设备管理员应用、Developer Options 和 Wireless Debugging。

一台阻止卸载或会恢复已移除应用的设备，需要的不只是再尝试一次普通卸载。应将其与敏感账户和网络断开，再寻求具备资质的事件响应支持。

组织应从另一台可信设备撤销活跃会话、更换可能暴露的凭证，并审查财务活动。可能有必要进行恢复出厂设置，但在调查重要时，响应人员应保留证据。

RatHat Android 恶意软件值得关注，因为它将可适应的导航能力与持久的设备控制结合在一起。决定性问题不在于其 AI 能否按下下一个按钮，而在于防御者能否遏制其中的每一个组成部分。