警惕“NFC诓骗鬼魂”：针对中国区用户的NFC中继攻击及恶意软件深度分析

颁布功夫 2026-01-23

第一章 概述


2026年1月21日，，，，，，，8827太阳集团ADLab在威胁狩猎中捕获到一款针对中国用户定造的NFC中继攻击样本。。。 。。。通过溯源分析，，，，，，，我们发现该样本是一款基于臭名远扬的NFU Pay（恶意软件即服务MaaS）生态而定造的恶意代码，，，，，，，其攻击指标聚焦于中国境内用户群体。。。 。。。与传统银行木马依赖垂钓页面窃取账户凭证或拦截短信验证码的攻击模式分歧，，，，，，，NFC中继攻击利用了近场通讯技术的物理个性，，，，，，，使攻击者可能即时获取被盗资金，，，，，，，有效绕过了银行转账延长到账等传统风控措施。。。 。。。


该攻击样本通过"读取端"设备(受害者设备)近场窃取受害者银行卡APDU指令，，，，，，，经C2服务器实时路由至"接管端"设备；；；；；；；接管端利用HCE职能模拟银行卡与POS机交互，，，，，，，实现毫秒级双向中继。。。 。。。全程POS机无法觉察买卖响应现实来自远程真实卡片，，，，，，，导致非接触式盗刷。。。 。。。为了便于后续威胁追踪和谍报共享，，，，，，，我们将新发现的恶意软件定名为“NFC诓骗鬼魂(NFC-Ghost)”。。。 。。。该恶意软件除了被黑客用于隐秘盗取受害者财帛表，，，，，，，还常被电信诳骗分子用于骗刷银行卡、信誉卡等近场买卖环节，，，，，，，并且还时时被用于国际间的洗钱活动。。。 。。。


“NFC诓骗鬼魂”的开发指标拥有显著针对性和主张性，，，，，，，好比其利用界面、提醒信息、日志输出均选取简体中文；；；；；；；客户端模式标识从英文“POS_terminal/Card_reader”改为中文“接管端/发送端”；；；；；；；API蹊径使用品牌拼音缩写“/zj/”（中际）；；；；；；；样本品牌名称“中际”及版本标识“Card-2.0/Card-2.3”等都批注其起头了针对中国市场的侵入。。。 。。。


在深度溯源过程中，，，，，，，我们发现NFU Pay平台已衍生出多个定制品牌，，，，，，，除本次分析的“NFC诓骗鬼魂”样本表，，，，，，，还蕴含PhantomCard、Lightning NFC等变种。。。 。。。当前NFC中继攻击领域已形成多个相互竞争的MaaS生态：SuperCard X是另一个由黑客运营的独立平台，，，，，，，其代码架构与NGate恶意软件存在类似性，，，，，，，两者均基于德国达姆施塔奸细业大学颁布的NFCGate开源项目演化而来。。。 。。。值得关注的是，，，，，，，SuperCard X同样被国内电信诳骗团伙用于执行盗刷、洗钱等犯法活动。。。 。。。


“NFC诓骗鬼魂”通过安卓系统的NFC HCE（Host Card Emulation，，，，，，，主机卡模拟）职能，，，，，，，实现银行卡APDU指令的实时中继转发。。。 。。。该恶意软件将发送端和接管端职能集成于统一利用中，，，，，，，攻击者在两台手机上装置统一利用后，，，，，，，通过登录界面别离选择“发送端”或“接管端”模式进行共同作业：发送端掌管诱导受害者将银行卡切近手机以读取NFC数据，，，，，，，接管端则在远程POS机或ATM机前模拟该银行卡实现支付或取现操作。。。 。。。整个攻击过程中，，，，，，，受害者的银行卡无需脱离其视线领域，，，，，，，攻击行为拥有极高的荫蔽性。。。 。。。


为深刻相识该威胁的技术细节和攻击手法，，，，，，，8827太阳集团ADLab对捕获的样本进行了全面的逆向分析工作，，，，，，，涵盖追踪溯源和代码深度分解等多个维度。。。 。。。本汇报旨在为安全钻研人员提供详尽的技术参考，，，，，，，同时为通常用户提升安全防备意识提供领导。。。 。。。后续章节将具体论述8827太阳集团分析过程、技术发现以及相应的安全建议。。。 。。。


第二章 追踪溯源


在本次分析过程中，，，，，，，我们对捕获的恶意软件样本进行了全面的逆向分析和关联追踪。。。 。。。该恶意软件将发送端和接管端职能集成于统一利用中，，，，，，，用户通过登录界面选择运行模式，，，，，，，软件启动的主界面如图2-1所示。。。 。。。


图2-1.png

图2-1 恶意软件登录界面及模式选择


在分析过程中，，，，，，，我们发现该恶意软件的后盾治理系统仍处于活跃状态。。。 。。。后盾登录界面选取中文设计，，，，，，，支持用户名密码、手机短信验证以及企业微信等多种登录方式，，，，，，，如图2-2所示。。。 。。。


图2-2.png

图2-2 后盾登录界面


通过审查网站源码，，，，，，，我们把稳到页面描述显示为“bluewind-boot后盾权限治理系统”。。。 。。。经GitHub检索确认，，，，，，，攻击者直接复用了开源项目bluewind-boot（https://github.com/llllllxy/bluewind-boot）作为后端框架，，，，，，，因而后盾界面自身未能提供有效的攻击者溯源线索。。。 。。。


为进一步扩大样本集，，，，，，，我们以主Activity特点字符串“nfc.share.nfcshare.”作为关联查问前提，，，，，，，在多个样本库中进行检索，，，，，，，最终网络到该恶意软件家族的76个样本。。。 。。。通过对这些样本的证书署名信息、包名特点、利用名称等多个维度进行系统性分析，，，，，，，我们得以勾画出该恶意软件家族的技术演进脉络和攻击者的运营特点。。。 。。。


2.1 样本证书与署名分析


数字证书是Android利用的沉要身份标识，，，，，，，通过对网络到的76个样本进行证手札息提取和统计分析，，，，，，，我们发现该恶意软件家族在证书使用上出现出显著的法规性特点，，，，，，，这些特点为追踪攻击者活动轨迹和评估威胁规模提供了沉要凭据。。。 。。。


图2-3.png

图2-3 署名证书功夫线


证书署名功夫可能反映样本的天生功夫节点，，，，，，，是追踪恶意软件家族活动周期的沉要指标。。。 。。。如图2-3所示，，，，，，，我们对76个样本的证书署名功夫进行了统计分析，，，，，，，发现样本的功夫散布出现出显著的分层特点。。。 。。。


在早期样本方面，，，，，，，有8个样本使用了2008年签发的Android SDK默认调试证书，，，，，，，还有2个样本使用了2021年4月签发的证书。。。 。。。这些样本可能为早期开发测试版本，，，，，，，或是攻击者为钻营急剧分发而跳过正式署名人程的一时版本。。。 。。。


从正式运营功夫来看，，，，，，，最早的正状貌本署名功夫可追忆至2024年11月，，，，，，，共有6个样本在该月被署名，，，，，，，这一功夫节点与该家族在野表被初次发现的功夫根基吻合。。。 。。。进入2025年后，，，，，，，样本署名活动出现显著的增长态势：3月有5个样本、6月有3个样本、8月有11个样本。。。 。。。值得关注的是，，，，，，，2025年9月成为样本产出的绝对顶峰期，，，，，，，单月署名样本数量达到22个，，，，，，，占总样本量的28.9%。。。 。。。随后的10月份仍维持较高活跃度，，，，，，，有12个样本被署名；；；；；；；11月和12月别离有5个和1个样本。。。 。。。进入2026年1月，，，，，，，我们又捕获到1个最新样本，，，，，，，批注该家族仍在持续活跃运营。。。 。。。


这一功夫散布特点批注，，，，，，，该恶意软件家族背后的威胁行为者具备持续的开发和运营能力，，，，，，，且在2025年下半年显著加大了攻击投放力度——仅8月至10月三个月内就产出45个样本，，，，，，，占总量的59.2%。。。 。。。


图2-4.png

图2-4 证书宣告者类型散布


除署名功夫表，，，，，，，证书宣告者信息同样是追踪恶意软件家族的沉要维度。。。 。。。如图2-4所示，，，，，，，我们对76个样本的证书宣告者信息进行了分类统计，，，，，，，鉴别出8种典型的证书使用模式。。。 。。。


“xinjiang”自署名证书是该家族使用最宽泛的证书类型，，，，，，，共有37个样本选取，，，，，，，占总量的48.7%。。。 。。。这类证书的显著特点是在地理地位字段中统一使用“xinjiang”作为标识，，，，，，，证书主题中的国度（C）、省份（ST）、城市（L）字段均设置为“xinjiang”。。。 。。。更值得关注的是，，，，，，，其组织名称（O）和组织单元（OU）字段选取“两位随机字母+Unix功夫戳”的定名体式，，，，，，，如“O=yf1755531900072”。。。 。。。通过对功夫戳的解析，，，，，，，我们发现这些数值与样本现实署名功夫高度吻合，，，，，，，强烈暗示攻击者使用了自动化工具批量天生署名证书。。。 。。。


单一数字证书是第二大类，，，，，，，共15个样本使用，，，，，，，占比19.7%。。。 。。。这类证书的特点是主题极为简化，，，，，，，通常仅蕴含一个单一数字作为CN字段值，，，，，，，如“CN=1”、“CN=8789789”等。。。 。。。这种配置通常呈此刻早期开发版本或必要急剧分发的定造版本中，，，，，，，反映出攻击者在某些场景下优先思考分发效能。。。 。。。


Android调试证书共8个样本使用，，，，，，，占比10.5%。。。 。。。这类样本使用Android SDK自带的默认调试证书，，，，，，，署名肇始功夫为2008年。。。 。。。在正常�？？？ ？？⒘鞒讨校�，，，，，，调试证书仅用于测试阶段，，，，，，，该家族中存在此类样本批注这些可能是开发测试版本，，，，，，，或攻击者为急剧分发而跳过正式署名步骤。。。 。。。


其他自署名证书共5个样本，，，，，，，占比6.6%。。。 。。。这类证书体式各别，，，，，，，蕴含使用中文字符（如“CN=的撒娇好”）、地域标识（如“C=中国, ST=江苏”）或随机字符串等，，，，，，，反映了样正本源的分散性，，，，，，，可能涉及多个分发渠路或定造客户。。。 。。。


RC/852证书共4个样本，，，，，，，占比5.3%。。。 。。。这类证书在国度代码字段使用“852”（香港国际电话区号），，，，，，，可能是攻击者试图假装成香港开发者。。。 。。。使用此类证书的样本重要是早期版本，，，，，，，署名功夫集中在2025年3月。。。 。。。


“admin”自界说证书共4个样本，，，，，，，占比5.3%。。。 。。。这类证书所有字段均使用“admin”加随机字符串体式，，，，，，，与xinjiang证书类似显示出批量自动化天生特点，，，，，，，但选取分歧定名模板。。。 。。。使用此类证书的样本署名功夫集中在2025年11月至12月，，，，，，，可能代表攻击者后期选取的新署名战术。。。 。。。


“NFC/Dubai”证书共2个样本，，，，，，，占比2.6%。。。 。。。这类证书使用阿联酋（ARE）作为国度代码，，，，，，，迪拜作为城市标识，，，，，，，暗示可能是针对中东地域定造的版本。。。 。。。


伪造企业证书仅1个样本，，，，，，，占比1.3%。。。 。。。该样本使用“Innovation Hub”作为组织名称，，，，，，，混合使用新加坡和巴西的地理标识，，，，，，，意图通过正规企业名称提升可信度，，，，，，，躲避安全检测。。。 。。。


综合来看，，，，，，，证书宣告者的多样性反映了该恶意软件家族的MaaS运营特点：主题开发团队使用自动化工具批量天生xinjiang系列证书用于重要分发，，，，，，，同时为分歧地域的定造客户提供差距化的证书配置规划。。。 。。。


2.2 家族归属确认


通过对样本证书的统计分析，，，，，，，我们已初步勾画出该恶意软件家族的运营规模和活动周期。。。 。。。然而，，，，，，，证手札息仅能反映样本的署名特点，，，，，，，要正确确认家族归属，，，，，，，还必要从代码层面寻找直接证据。。。 。。。为此，，，，，，，我们选取代码比对分析步骤，，，，，，，将”NFC诓骗鬼魂“与已确认归属于NFU Pay平台的样本进行对比，，，，，，，从代码结构、主题类实现、通讯和谈等多个维度验证其同源性。。。 。。。


2.2.1 参照样本拔取


在网络到的76个样本中，，，，，，，我们把稳到一个包名为“nfc.share.nfcshare”的样本，，，，，，，其包名与我们用于关联检索的主Activity特点字符串齐全一致。。。 。。。该样本的利用名称为“NFU”，，，，，，，利用图标中同样蕴含NFU字样。。。 。。。通过对该样本的逆向分析，，，，，，，我们在其登录失败处置逻辑的Toast提醒信息中发现了明确的归属证据——“遇到问题联系：@nfupay666”，，，，，，，如图2-5所示。。。 。。。


图2-5.png

图2-5 NFU Pay的联系方式


@nfupay666是NFU Pay在Telegram平台的官方客服账号，，，，，，，如图2-6所示，，，，，，，这一发现直接证实该样本为NFU Pay平台官方分发的版本。。。 。。。


图2-6.png

图2-6 NFU Pay的联系方式


因而我们拔取该样本（MD5: 07a8dcccfc3c5496423923a0033dbe11）作为参照样本，，，，，，，与“NFC诓骗鬼魂”样本进行代码比对。。。 。。。


2.2.2 代码对比分析


通过GDA反编译工具对两个样本进行代码目录结构对比分析，，，，，，，我们发现两者的主题代码均位于“nfc.share.nfcshare”包蹊径下，，，，，，，拥有高度一致的模�？？？ ？？榛橹峁梗�，，，，，，如图2-7所示。。。 。。。


两个样本均蕴含一样的service和model子包结构。。。 。。。在service子包中，，，，，，，主题服务类EmulationService.java（NFC HCE卡模拟服务）和MqttService.java（WebSocket通折服务）的类名和包蹊径齐全一致。。。 。。。在model子包中，，，，，，，数据模型类MqttChannel.java（通路类型枚举）、NfcInfo.java（NFC数据封装）、WSMessage.java（WebSocket新闻体式）、CardInfo.java（卡片信息）同样维持一致。。。 。。。


两者的重要差距在于混合水平分歧。。。 。。。“NFC诓骗鬼魂”经过了更强的代码混合处置，，，，，，，部门辅助类被沉定名为单字母类名（如a.java、b.java、c.java等），，，，，，，而参照样本（“NFU”）保留了原始的类名（如ApiService.java、NetworkUtils.java等）。。。 。。。但值妥贴心的是，，，，，，，两个样本的主题职能类定名均维持不变，，，，，，，这批注它们共享一样的代码基础框架。。。 。。。


图2-7.png

图2-7 样本代码目录结构


在代码结构一致的基础上，，，，，，，我们进一步对比了两个样本的主题职能实现代码。。。 。。。


EmulationService是NFC中继攻击的主题服务类，，，，，，，掌管接管POS机的APDU指令并转发至C2服务器。。。 。。。如图2-8所示，，，，，，，两个样本的EmulationService实现逻辑齐全一致：均继承自Android系统的HostApduService类。。。 。。。onDeactivated函数内的打印日志的TAG都一样，，，，，，，唯一的差距是分析样本对日志字符串进行了NPStringFog加密处置，，，，，，，而参照样本保留了明文日志。。。 。。。


图2-8.png

图2-8 EmulationService主题代码对比


MqttChannel枚举类界说了WebSocket通讯的通路类型。。。 。。。如图2-9所示，，，，，，，两个样本的MqttChannel界说齐全一样，，，，，，，均蕴含FETCH_CHANNEL、SEND_CHANNEL、LOG_CHANNEL、CARD_INFO_CHANNEL、CARD_REMOVED、NOTIFICATION_CHANNEL、ANSWER_CHANNEL、OFFLINE_CHANNEL共8种通路类型，，，，，，，枚举值的名称和挨次齐全一致。。。 。。。


图2-9.png

图2-9 MqttChannel枚举界说对比


综合以上代码层面的直接证据，，，，，，，我们能够确认本次分析的“NFC诓骗鬼魂”属于NFU Pay MaaS生态系统的定造产品。。。 。。。这种为分歧客户定造独立品牌的做法切合MaaS平台的典型贸易运营模式——主题开发团队提供基础恶意软件框架，，，，，，，下游客户可凭据需要定制品牌名称、界面风格和指标地域。。。 。。。在我们网络的样本中，，，，，，，除“中际”表还发现了“NFU”、“T4”、“鲲鹏支付”、“云联”、“EQUIPE GHOST”等多个品牌名称，，，，，，，这些均为NFU Pay平台为分歧客户定造的产品变种。。。 。。。


2.2.3 基础设施关联分析


除代码层面的同源性证据表，，，，，，，我们还通过C2基础设施的关联分析进一步验证了家族归属关系。。。 。。。


在“NFC诓骗鬼魂”样本的逆向分析中，，，，，，，我们提取到其C2服务器域名www.zjshare.xyz。。。 。。。通过查问该域名的WHOIS注册信息，，，，，，，如图2-10所示，，，，，，，该域名注册功夫为2025年11月27日。。。 。。。


图2-10.png

图2-10 域名www.zjshare.xyz的WHOIS信息


对该域名进行DNS解析，，，，，，，得到其指向的服务器IP地址为185.106.176.32。。。 。。。值妥贴心的是，，，，，，，该IP地址在另一个“中际”样本（MD5: 45902fa3f8879a18c97b12fbb186e196）中以硬编码大局直接出现，，，，，，，该样本的证书署名功夫为2025年12月1日，，，，，，，仅迸昨名注册功夫晚4天。。。 。。。这一功夫关联印证了前文证书署名功夫溯源的正确性，，，，，，，同时批注攻击者在2025年11月底至12月初期间实现了C2基础设施的部署和样本的署名分发。。。 。。。


通过威胁谍报平台对该IP地址进行关联查问，，，，，，，我们发现它还被其他NFU Pay家族变种所使用，，，，，，，其中蕴含品牌名为“鲲鹏NFC”的样本，，，，，，，如图2-11所示。。。 。。。


图2-11.png

图2-11 通过IP关联发现的"鲲鹏NFC"样本


这一发现批注，，，，，，，NFU Pay平台为旗下多个品牌变种提供统一的C2基础设施服务，，，，，，，“中际”、“鲲鹏NFC”等品牌共享一样的后端服务器。。。 。。。这种架构设计进一步印证了该恶意软件家族的MaaS运营模式。。。 。。。


2.3 攻击者画像


基于上述分析，，，，，，，我们能够勾画出该恶意软件背后威胁行为者的根基画像。。。 。。。


（1）从说话特点来看，，，，，，，样本的用户界面文本、日志输出信息、代码注解均使用简体中文，，，，，，，批注开发者为中文母语使用者。。。 。。。例如，，，，，，，在LoginActivity.java中能够看到“登录要求失败”、“可能网络不不变，，，，，，，请沉试”等中文提醒信息。。。 。。。

（2）从运营模式来看，，，，，，，该恶意软件选取MaaS（恶意软件即服务）贸易模式，，，，，，，通过Telegram渠路（@nfupay666）进行销售和客户支持。。。 。。。这种模式允许攻击者将恶意软件作为服务出租给下游犯罪分子，，，，，，，降低了执行NFC中继攻击的技术门槛。。。 。。。

（3）从技术能力来看，，，，，，，威胁行为者具备Android逆向开发能力，，，，，，，熟悉NFC/EMV支付和谈，，，，，，，并持续迭代混合匹敌技术以躲避安全检测。。。 。。。从版本的技术演进能够看出，，，，，，，攻击者在字符串加密、包名随机化、利用名称混合等方面进行了显著加强。。。 。。。


第三章 技术分析


本章节将从攻击道理、主题职能模�？？？ ？？椤⒋牖旌霞际跞鑫榷浴癗FC诓骗鬼魂”恶意软件进行深刻分解，，，，，，，并结合现实攻击场景还原齐全的攻击链路。。。 。。。


3.1 攻击道理与架构设计


3.1.1 NFC中继攻击道理


“NFC诓骗鬼魂”恶意软件的主题攻击道理是利用Android系统的NFC HCE（Host Card Emulation，，，，，，，主机卡模拟）职能实现银行卡数据的实时中继。。。 。。。HCE是Android 4.4引入的技术个性，，，，，，，允许利用法式在无需安全元件（SE）的情况下模拟NFC卡片，，，，，，，正本用于移动支付等合刑场景。。。 。。。然而，，，，，，，攻击者滥用这一技术，，，，，，，将其刷新为银行卡数据的远程中继工具。。。 。。。


如图3-1所示，，，，，，，整个攻击过程涉及五个关键角色：受害者银行卡、发送端设备（Reader）、C2服务器、接管端设备（Tapper）、POS机/ATM机。。。 。。。攻击流程如下：发送端设备通过NFC读取受害者银行卡的APDU数据，，，，，，，并通过WebSocket实时转发至C2服务器；；；；；；；C2服务器将数据路由至接管端设备；；；；；；；接管端设备利用HCE职能模拟该银行卡，，，，，，，响应POS机的APDU要求；；；；；；；POS机的要求同样沿原路返回至真实银行卡获取响应。。。 。。。整个中继过程在毫秒级功夫内实现，，，，，，，POS机无法分辨响应来自本地卡片还是远程中继。。。 。。。


图3-1.png

图3-1 NFC中继攻击道理示意图


3.1.2 双端架构设计


“NFC诓骗鬼魂”恶意软件选取双端架构设计，，，，，，，将发送端（Reader）和接管端（Tapper）职能集成于统一利用中，，，，，，，用户通过登录界面的模式选择控件切换运行模式，，，，，，，如图3-1所示。。。 。。。这种设计简化了攻击者的部署流程，，，，，，，只需在两台设备上装置统一利用并选择分歧模式即可实现配对。。。 。。。


通过度析LoginActivity的源码，，，，，，，我们发现模式切换通过RadioGroup控件实现。。。 。。。当用户选择接管端模式时，，，，，，，利用将clientId设置为接管端，，，，，，，并将isPosMode标志保留为true；；；；；；；当用户选择“发送端”模式时，，，，，，，clientId设置为“发送端”，，，，，，，isPosMode标志保留为false。。。 。。。模式状态通过SharedPreferences悠久化存储，，，，，，，确保利用沉启后可能复原之前选择的运行模式，，，，，，，模式选择的监听代码如图。。。 。。。值妥贴心的是，，，，，，，早期NFU版本使用英文标识“POS_terminal”和“Card_reader”作为clientId，，，，，，，而“NFC诓骗鬼魂”版本改用中文标识，，，，，，，这一变动可能是为了适应国内用户群体。。。 。。。


图3-2.png

图3-2 监听Raido的选择，，，，，，，设置clientId


在发送端模式下，，，，，，，恶意软件的重要职能是读取受害者银行卡的NFC数据。。。 。。。当受害者在攻击者的诱导下将银行卡切近手机NFC感应区时，，，，，，，手机作为NFC读卡器与银行卡成立ISO 14443通讯，，，，，，，恶意软件捕获所有APDU交互数据并通过WebSocket实时转发至C2服务器。。。 。。。


在接管端模式下，，，，，，，恶意软件的重要职能是模拟银行卡。。。 。。。EmulationService作为HCE服务运行，，，，，，，当攻击者将手机切近POS机时，，，，，，，恶意软件接管POS机发送的APDU指令，，，，，，，通过WebSocket转发至C2服务器获取真实银行卡的响应，，，，，，，再将响应返回给POS机实现买卖，，，，，，，接管端工作界面如图3-3所示。。。 。。。


图3-3.png

图3-3 接管端界面


3.2 主题职能模�？？？ ？？榉治�


本节将深刻分析“NFC诓骗鬼魂”恶意软件的主题职能模�？？？ ？？槭迪郑�，，，，，，蕴含NFC卡模拟服务、实时通讯模�？？？ ？？椤2通讯基础设施等关键组件。。。 。。。


3.2.1 NFC HCE卡模拟服务


在AndroidManifest.xml中，，，，，，，如图3-4所示，，，，，，，EmulationService的服务申明体现了HCE服务的尺度配置模式。。。 。。。服务被注册为android.nfc.cardemulation.category.PAYMENT类别，，，，，，，使其可能响应支付类NFC要求。。。 。。。permission属性设置为android.permission.BIND_NFC_SERVICE，，，，，，，确保只有系统过程可能绑定该服务，，，，，，，预防第三方利用恶意挪用。。。 。。。foregroundServiceType属性值为0x10（对应connectedDevice类型），，，，，，，这是Android 10引入的前台服务类型申明，，，，，，，确保服务在后盾运行时拥有较高的过程优先级，，，，，，，不会被系统内存治理机造等闲终止。。。 。。。meta-data标签引用的aid_list.xml文件界说了服务响应的AID（Application Identifier）列表，，，，，，，决定了哪些类型的NFC卡片要求会被路由至该服务。。。 。。。


图3-4.png

图3-4 EmulationService主题代码实现


EmulationService是实现NFC中继攻击的主题服务类，，，，，，，继承自Android系统的HostApduService基类。。。 。。。HostApduService是Android 4.4（API Level 19）引入的系统服务，，，，，，，专门用于实现基于主机的NFC卡模拟职能。。。 。。。当POS机或ATM机向手机发送APDU（Application Protocol Data Unit）指令时，，，，，，，Android系统会自动将指令路由至已注册的HCE服务，，，，，，，并回调processCommandApdu步骤进行处置。。。 。。。


该服务的主题实现如图3-5所示。。。 。。。processCommandApdu步骤是APDU指令处置的入口点，，，，，，，其实现逻辑简洁而关键：首先挪用Utils.encodeHexStr步骤将接管到的原始字节数组转换为十六进造字符串体式，，，，，，，而后通过Utils.mqttService.pushMessageToMqtt步骤将数据发送至FETCH_CHANNEL通路，，，，，，，最终经由WebSocket转发至C2服务器。。。 。。。该步骤返回null而非现实响应数据，，，，，，，批注恶意软件选取异步响应机造——服务端收到APDU指令后，，，，，，，将其转发至发送端获取真实银行卡的响应，，，，，，，再通过SEND_CHANNEL通路回传，，，，，，，最后由EmulationService挪用sendResponseApdu步骤将响应返回给POS机。。。 。。。当处置过程中产生异常时，，，，，，，步骤返回“6F00”状态字，，，，，，，这是ISO 7816-4尺度界说的通用谬误状态码，，，，，，，暗示“无精确诊断信息”。。。 。。。


图3-5.png

图3-5 EmulationService主题代码实现


在服务性命周期治理方面，，，，，，，onCreate步骤将服务事俘保留至Utils.emulationService静态变量以便全局接见，，，，，，，同时更新界面状态批示器并向NOTIFICATION_CHANNEL通路发送“HCE已启动”通知。。。 。。。onDeactivated步骤在NFC链路断开时被回调，，，，，，，凭据断开原因（链路迷失或被其他利用抢占）纪录相应日志。。。 。。。onDestroy步骤掌管算帐资源，，，，，，，蕴含置空静态引用、发送服务终场通知、通过Handler在主线程更新界面状态。。。 。。。


3.2.2 WebSocket实时通讯模�？？？ ？？�


MqttService掌管成立与C2服务器的WebSocket长衔接，，，，，，，实现APDU数据的双向实时传输。。。 。。。值妥贴心的是，，，，，，，只管类名蕴含“Mqtt”字样，，，，，，，但通过代码分析确认该模�？？？ ？？橄质凳褂肳ebSocket和谈而非MQTT和谈进行通讯，，，，，，，这种定名方式可能是开发者为混合安全分析而有意设置的误导生定名，，，，，，，MqttService内部的成员函数如图3-6所示。。。 。。。


图3-6.png

图3-6 假装成Mqtt模�？？？ ？？榈腤ebSocket代码


MqttService内部守护一个WebSocket客户端治理器事俘wsClientManager，，，，，，，掌管治理与C2服务器的衔接性命周期。。。 。。。connect步骤接管服务器URL作为参数，，，，，，，在成立衔接前会查抄当前衔接状态以预防沉复衔接。。。 。。。disconnect步骤通过发送关关�。。。 。。。╟lose frame，，，，，，，状态码1000暗示正常关关）断开衔接并算帐有关状态。。。 。。。pushMessageToMqtt步骤是新闻发送的主题接口，，，，，，，该步骤在新线程中执行现实的发送逻辑，，，，，，，预防阻塞主线程影响用户界面响应。。。 。。。


图3-7.png

图3-7 MqttService的connect和disconnect函数


通讯和谈选取JSON体式封装新闻。。。 。。。WSMessage对象作为新闻载体，，，，，，，其字段界说如表3-1所示。。。 。。。


表3-1.png

表3-1 WSMessage新闻结构


NfcInfo对象封装APDU数据的具体内容，，，，，，，其字段界说如表3-2所示。。。 。。。


表3-2.png

表3-2 NfcInfo数据结构


MqttChannel枚举类界说了8种通路类型，，，，，，，实现了在单一WebSocket衔接上的多路复用通讯，，，，，，，各通路职能如表3-3所示。。。 。。。


表3-3.png

表3-3 MqttChannel通路类型界说


这种多通路设计使得分歧类型的数据可能在统一衔接上并行传输，，，，，，，同时维持逻辑上的隔离。。。 。。。此表，，，，，，，恶意软件还实现了买卖金额解析职能，，，，，，，可能从APDU指令流中提取买卖金额和钱币代码（遵循ISO 4217尺度），，，，，，，使攻击者能够实时监控每笔盗刷买卖的金额。。。 。。。


3.2.3 C2通讯基础设施


通过对样本的逆向分析，，，，，，，我们提取到该恶意软件的C2通讯架构。。。 。。。恶意软件启动后必要先实现服务器登录认证，，，，，，，登录流程如图3-8所示。。。 。。。


图3-8.png

图3-8 用户登录函数


登录要求选取JSON体式封装，，，，，，，蕴含以下参数：account（账号）、password（密码）、rcid（设备Android ID，，，，，，，用于唯一标识设备）、mode（运行模式标识）。。。 。。。服务器验证通过后返回WebSocket衔接地址和端口信息，，，，，，，客户端据此成立实时通讯通路用于APDU数据中继。。。 。。。


API服务器地址在代码中经过NPStringFog加密存储，，，，，，，解密后得到基础地址为www.zjshare.xyz，，，，，，，选取HTTPS和谈进行加密通讯。。。 。。。值妥贴心的是，，，，，，，API要求蹊径统一使用“/zj/api/”前缀，，，，，，，其钟装zj”为该恶意软件品牌名称“中际”的拼音首字母缩写，，，，，，，这一定名特点与样本的品牌标识维持一致。。。 。。。重要API端点如表3-4所示。。。 。。。


表3-4.png

表3-4 C2服务器API端点


3.3 代码�；；；；；；；び肫サ屑际�


通过对分歧时期样本的对比分析，，，，，，，我们观察到该恶意软件家族在代码�；；；；；；；ぜ际跎铣鱿窒灾牡肚飨颍�，，，，，，反映出攻击者持续提升匹敌安全检测能力的意图。。。 。。。本节将从字符串加密、标识符混合、加壳战术、权限配置四个维度，，，，，，，具体分析“NFC诓骗鬼魂”样本所选取的代码�；；；；；；；ぜ际跫捌溲萁氐�。。。 。。。


3.3.1 字符串加密技术


早期NFU版本的敏感字符串以明文大局存储在代码中，，，，，，，蕴含C2服务器地址、API端点、日志标签、提醒信息等，，，，，，，这为安全钻研人员的静态分析提供了方便。。。 。。。我们本次分析的版本则引入了NPStringFog自界说字符串加密规划，，，，，，，有效阻止了基于字符串特点的静态检测。。。 。。。通过对NPStringFog.java源码的逆向分析，，，，，，，我们齐全还原了其加解密算法，，，，，，，如图3-9所示。。。 。。。该规划选取HEX编码结合XOR异或运算的两阶段处置流程：加密时首先将原始字符串转换为HEX编码的字节序列，，，，，，，而后使用硬编码密钥“npmanager”对字节数组进行逐字节循环XOR运算。。。 。。。解密时执行逆向操作，，，，，，，decode步骤首先将HEX字符串还原为字节数组，，，，，，，使用一样密钥进行XOR运算恢复原始数据，，，，，，，最后将特殊象征“$-sxg-$”代替为反斜杠字符。。。 。。。这种加密规划固然算法单一、密钥固定，，，，，，，但足以将敏感字符串从静态分析视野中暗藏，，，，，，，增长了自动化检测的难度。。。 。。。


图3-9.png

图3-9 NPStringFog字符串加解密算法


3.3.2 包名与利用名称混合


在包名战术方面，，，，，，，早期NFU版本使用相对固定的包名体式，，，，，，，如nfc.share.nfcshare、com.nfupay666.rc等，，，，，，，这些定名固然不切合常见合法利用的包名规范，，，，，，，但仍拥有肯定法规性，，，，，，，容易被安全厂商参与检测黑名单。。。 。。。我们本次分析的版本选取齐全随机化的包名战术，，，，，，，如sckfkndjdrzays.cezqfefjwxkqrgd.sioivedygyuhq，，，，，，，由三段随机字母组成，，，，，，，每段长度在10-15个字符之间，，，，，，，有效躲避了基于包名特点的检测规定。。。 。。。


在利用名称方面，，，，，，，早期版本使用单一的中文名称如“NFU”、“中际”，，，，，，，未选取任何混合技术。。。 。。。本次分析的版本则在利用名称中嵌入了大量Unicode零宽字符，，，，，，，如图3-10所示。。。 。。。通过度析AndroidManifest.xml中的android:label属性，，，，，，，我们发现显示为“中际·2?3”的名称现实蕴含大量不私见字符，，，，，，，蕴含零宽衔接符（U+200D，，，，，，，ZWJ）、零宽非衔接符（U+200C，，，，，，，ZWNJ）、零宽空格（U+200B，，，，，，，ZWSP）、词衔接符（U+2060，，，，，，，WJ）等。。。 。。。这些字符在视觉上齐全不私见，，，，，，，但会显著扭转字符串的二进造暗示和哈希值，，，，，，，从而滋扰基于利用名称的人为鉴别和自动化检测。。。 。。。


图3-10.png

图3-10 超长的利用名称造成自动化分析系统异常


3.3.3 加壳战术演进


该恶意软件家族的代码�；；；；；；；ふ绞醭鱿殖鱿灾难萁氐�。。。 。。。早期NFU版本未选取任何代码�；；；；；；；ご胧�，，，，，，敏感字符串以明文大局存储。。。 。。。随着安全厂商检测能力的提升，，，，，，，攻击者起头引入代码�；；；；；；；せ�。。。 。。。以MD5为8abdc38030d6686588f9a491e2a93957的样本为例，，，，，，，该样本选取了自界说加固规划，，，，，，，通过混合处置预防主题代码直接露出，，，，，，，加固后的代码目录结构如图3-11所示。。。 。。。


图3-11.png

图3-11 加固后的代码目录结构


然而，，，，，，，“NFC诓骗鬼魂”并未选取加壳�；；；；；；；ぃ�，，，，，，仅使用NPStringFog字符串加密规划。。。 。。。这一战术调整可能出于以下考量：加壳工具自身会引入可被识此外特点码，，，，，，，安全厂商可通过检测壳特点象征可疑样本；；；；；；；同时加壳会增长利用启动功夫和运行时内存开销。。。 。。。选取轻量级的字符串加密规划，，，，，，，在维持肯定�；；；；；；；こ尚У耐苯档土司蔡氐懵冻龇缦眨�，，，，，，体现了攻击者在荫蔽性与防护强度之间的衡量。。。 。。。


3.3.4 权限最幼化战术


通过度析AndroidManifest.xml的权限申明，，，，，，，我们发现该恶意软件选取了“最幼权限”战术，，，，，，，仅要求实现主题职能所必须的5项权限，，，，，，，如表格3-5所示。。。 。。。


表3-5.png

表3-5 申请权限名称和职能


同时通过uses-feature标签申明android.hardware.nfc和android.hardware.nfc.hce两项硬件个性要求，，，，，，，并将required属性设置为true，，，，，，，这意味着该利用只能装置在支持NFC HCE职能的设备上。。。 。。。


与传统银行木马相比，，，，，，，该恶意软件的权限要求极为精简。。。 。。。传统银行木马通�；；；；；；；嵋笫蠲舾腥ㄏ蓿�，，，，，，蕴含READ_SMS和RECEIVE_SMS用于拦截短信验证码、READ_CONTACTS用于窃取通讯录、READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE用于接见存储空间、BIND_ACCESSIBILITY_SERVICE用于获取无阻碍服务权限以实现界面劫持等。。。 。。。这些权限要求往往会引起用户警惕，，，，，，，也容易被安全软件象征为可疑行为。。。 。。。


该恶意软件选取最幼权限战术的优势在于：首先，，，，，，，精简的权限列表降低了用户在装置时的警惕性，，，，，，，用户更容易接受一个只要求NFC和网络权限的利用；；；；；；；其次，，，，，，，较少的敏感权限要求使得样本更难被基于权限特点的安全检测规定鉴别；；；；；；；最后，，，，，，，这种战术也体现了攻击者对Android安全机造的深刻理解和成熟的躲避检测经验。。。 。。。


第四章 总结及建议


经过全面深刻的技术分析，，，，，，，我们对“NFC诓骗鬼魂”恶意软件及其归属的NFU Pay家族形成了系统性意识。。。 。。。该恶意软件对准中国用户，，，，，，，其利用Android系统的NFC HCE职能实现银行卡数据的实时中继，，，，，，，使攻击者可能在受害者绝不知情的情况下实现盗刷或取现操作。。。 。。。由于攻击过程中受害者的银行卡始终在其视线领域内，，，，，，，加之MaaS贸易模式降低了攻击执行门槛，，，，，，，我们将该恶意软件家族的威胁等级评估为高危。。。 。。。从样本署名功夫散布来看，，，，，，，该家族在2025年下半年显著加大了攻击投放力度，，，，，，，仅8月至10月就产出45个样本，，，，，，，占总量的59.2%，，，，，，，显示出持续活跃的运营态势。。。 。。。据公开报路，，，，，，，我国境内已有多名受害者因习染该家族样本遭逢经济损失，，，，，，，公安机关也已破获多起利用此类技术执行的电信网络诳骗案件。。。 。。。


对于通常用户而言，，，，，，，防备NFC中继攻击的关键在于提高安全意识。。。 。。。用户应仅从官方利用商店下载利用法式，，，，，，，对通过短信、社交媒体或陌生网站提供的下载链接维持高度警惕。。。 。。。必要出格把稳的是，，，，，，，任何要求将银行卡切近手机进杏装验证”或“安全检测”的操作都应果断回绝，，，，，，，正规金融机构不会选取此类方式进行身份核验。。。 。。。建议用户开启银行买卖短信通知职能，，，，，，，一旦发现异常买卖应立即联系银行冻结账户并向公安机关报案。。。 。。。


对于银行和支付机构而言，，，，，，，建议加强NFC支付买卖的异常检测能力，，，，，，，沉点关注买卖地址与持卡人常用地址不符、短功夫内涵分歧地址产生多笔买卖等异常特点。。。 。。。�？？？ ？？伤伎家肷璞钢肝萍际跫鹇蚵籼嵋樯璞福�，，，，，，并对高风险买卖增长短信确认或语音电话确认等二次验证机造。。。 。。。此表，，，，，，，金融机构应通过官方渠路向用户遍及NFC中继攻击的风险特点，，，，，，，援手用户鉴别和防备社会工程诱导。。。 。。。



IOC

注：以下为我们在钻研期间网络到的样本的IOC信息

[1]ws://185.106[.]176.32:8091/

[2]http://185.106[.]176.32:8080/zj/api/user_logout

[3]http://185.106[.]176.32:8080/zj/api/user_config

[4]http://185.106[.]176.32:8080/zj/api/user_login

[5]https://www.zjshare[.]xyz/zj/api/

[6]45902fa3f8879a18c97b12fbb186e196

[7]49961202edb37c093201b71907f742d4

[8]8017741d7840cb9d6a322de44771a1d3

[9]8abdc38030d6686588f9a491e2a93957

[10]ff54db962a351d853c551b258dbcc30e



8827太阳集团积极防御尝试室（ADLab）


ADLab成立于1999年，，，，，，，是中国安全行业最早成立的攻防技术钻研尝试室之一，，，，，，，微软MAPP打算主题成员，，，，，，，“黑雀攻击”概想首推者。。。 。。。截至目前，，，，，，，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计颁布安全缝隙7000余个，，，，，，，持续维持国际网络安全领域一流水准。。。 。。。尝试室钻研方向涵盖基础安全钻延注运营商基础网络设施安全钻延注移动终端安全钻延注云安全钻延注信创安全钻延注物联网安全钻延注车联网安全钻延注工控安全钻延注无线安全钻延注数据安全钻延注AI安全钻延注低空安全钻延注高级威胁钻延注攻防系统建设。。。 。。。钻研成就利用于产品主题技术钻延注国度沉点科技项目攻关、专业安全服务等。。。 。。。


adlab.jpg