1. 样本基础画像与静态分析思路1.1 样本信息与建包逻辑先把这个样本的基本情况摆出来。这个名为“天眼查询系统”的APK体积只有3.99MB从名字看像是一个正常的业务查询工具但实际上是典型的安卓恶意样本。包名伪装成com.system.query应用名称直接就叫“天眼查询系统”这种命名方式在恶意样本里很常见——起一个容易让人放松警惕的名字诱导用户主动安装。3.99MB的体积在今天的安卓恶意样本里属于偏小的类型。为什么值得关注因为现在绝大多数正规商业应用动辄几十MB甚至上百MB而恶意样本通常保持小体积有两个原因一是方便捆绑进各种非官方渠道的安装包里降低分发成本二是说明这个APK只是一个“壳”真正的恶意代码可能通过云端下发或者后续动态加载3.99MB只是为恶意行为开了一个入口并不代表全部攻击能力。拆开这个APK看目录结构classes.dex只有几百KBassets目录下有一层加密数据lib目录里有三个so文件分别对应armeabi-v7a、arm64-v8a和x86三种架构。这种多架构适配并非恶意样本特色但这个小体积样本依然保留对旧架构的兼容说明作者是考虑过覆盖旧设备的投放目标并不限定高端机型。拿到样本后的第一件事不是急着执行而是先做静态信息收集。用专业工具查看APK的签名信息发现这是一个自签名证书证书组织名伪造为一家不存在的软件公司有效期只有一年——正常商业应用通常用两年以上有效期的证书短期证书说明作者不想在签名信息里暴露太多线索也方便快速更换新证书绕过检测。1.2 静态拆解体积虽小、五脏俱全的伪装术用jadx打开这个APK主Activity的入口名非常有迷惑性叫com.system.query.ui.MainActivity布局文件也很简单界面上只有一个输入框和一个查询按钮看起来就像一个简单的“车牌查询”工具。但细看代码逻辑后发现所有的界面展示都是幌子真正的逻辑编写在onCreate里的一个异步线程中。这个异步线程先做三件事检测当前是否运行在模拟器环境中、检测是否有调试器附加、读取本机基础设备信息。模拟器检测的方式比较老套但有效——检查Build字段里是否含有goldfish、ranchu等模拟器特征同时检查/proc/cpuinfo里的硬件信息还会尝试读取/sys/qemu_trace这类模拟器独有路径。如果检测到模拟器环境样本会直接走一条假分支界面正常显示查询结果但不会触发真正的恶意行为只有检测到真实设备时才会继续往下执行。这种“设备环境感知”设计在恶意样本里越来越普遍目的就是对抗安全分析人员用模拟器做动态分析。分析这种样本时不能只看表面运行结果需要在静态分析阶段就把代码路径摸清楚找到模拟器检测的分支再针对性绕过。静态分析阶段还有一个关键发现——这个APK的AndroidManifest.xml里申请了大量与界面功能完全无关的权限这个点非常值得展开下一节细说。2. 权限申请与行为模型拆解2.1 权限矩阵解读一个查询工具为什么要读短信和通讯录把“天眼查询系统”申请的权限拉个清单会发现一个很典型的“权限滥用”结构。一个只做查询的工具类应用正常只需要网络权限就够了但这个样本申请了以下高风险权限权限风险等级实际用途RECEIVE_SMS极高监听并劫持短信验证码READ_SMS极高读取历史短信内容READ_CONTACTS高上传通讯录数据ACCESS_FINE_LOCATION高获取精确地理位置RECORD_AUDIO高后台录音CAMERA高调用摄像头拍照REQUEST_INSTALL_PACKAGES高静默安装其他恶意APKSYSTEM_ALERT_WINDOW中悬浮窗攻击、界面劫持RECEIVE_BOOT_COMPLETED中开机自启动WAKE_LOCK低保持设备唤醒状态这些权限组合在一起勾勒出的行为模型已经很清楚这是一个集隐私窃取、短信劫持、远程控制、恶意推广于一体的综合性远控木马。特别值得注意的是REQUEST_INSTALL_PACKAGES这个权限它允许应用在没有用户主动确认的情况下发起安装请求很多恶意样本通过这个权限实现“下载即安装”的静默更新让恶意代码可以随时升级成更危险的版本。短信权限的用途很典型国内很多业务都依赖短信验证码做身份验证恶意样本拿到短信权限后可以实时拦截验证码配合前面窃取到的手机号、身份证信息就能尝试撞库、盗号、甚至盗刷账户资产。2.2 恶意行为链从用户点击到数据外传把恶意行为的执行链梳理出来大概是这样的路径用户从非官方渠道下载安装“天眼查询系统”并打开应用首先检查设备环境确认是真实手机后进入主流程。主流程第一步是收集设备基础信息——手机型号、系统版本、IMEI、MAC地址、已安装应用列表这些信息被打包成一份设备指纹第二步读取通讯录、短信内容和位置信息组建一份个人隐私数据包第三步把这两份数据通过加密网络通道上传到远程服务器。数据上传完成后样本会进入一个“待命”状态持续接收服务器下发的指令。指令类型包括弹出指定广告页面、下载安装指定APK、录制一段音频、拍摄一张照片、获取指定应用的账号信息。整个行为链里用户界面上那个查询按钮只是一个摆设无论输入什么内容界面都会显示“未找到相关记录”而背后的恶意行为一直在悄悄执行。从实际运行的情况看这个样本还自带一个“防卸载”的心机设计——它注册了DeviceAdminReceiver设备管理器组件激活后用户正常卸载会被拦截需要先解除设备管理器才能卸载。这个机制不算新但确实给普通用户造成了非常大的困扰很多用户发现手机不对劲却没办法卸载只能恢复出厂设置。3. 动态行为监控与逆向溯源3.1 运行沙箱监测需要处理的反模拟器绕过静态分析只能拼出行为模型真正要坐实恶意行为还得考动态分析。我在本地搭了一套安卓动态分析环境用Frida做函数级别的Hook同时用抓包工具配合监控网络请求一步步看这个样本到底做了什么。遇到的第一个问题就是反模拟器检测。前面静态分析时发现样本会检测运行环境直接在模拟器里打开恶意行为根本不会触发。绕过的思路是Hook掉它的检测函数让它误认为当前是真实设备。具体操作上用Frida脚本Hook了Build.FINGERPRINT、Build.MODEL等属性同时拦截了检测/sys/qemu_trace文件的逻辑让检测函数永远返回“非模拟器”。不过要让样本真正进入恶意流程还需要构造一个足够“真实”的环境。我的做法是准备了一台已经Root的Android备用手机在真机上做动态监控这也符合目前业内针对反模拟器样本的主流做法——与其和检测逻辑缠斗不如直接上真机。真机分析时我在系统层用strace跟踪系统调用应用层用Frida挂钩关键函数同时用抓包工具抓取所有网络流量。3.2 通信行为分析加密数据外传的细节动态运行约5分钟后网络监控发现这个样本开始向远程服务器发起请求。请求频率不高约每30秒一次数据包内容经过编码处理长度在1KB左右看起来是把收集到的隐私数据经过处理后回传。进一步定位后确认样本先把隐私数据拼接成一个JSON结构再进行加密处理最后通过HTTP POST方式上传。对方服务器的地址使用的是直接的IP加路径没有走正规域名这个特征很典型——正规服务都会用域名配合证书保证链路安全恶意样本直接用IP是为了节省成本、便于随时更换服务器。数据包外层看起来只是普通文本但拆开分析后发现内容是加密后的密文仅靠抓包无法还原明文还需要在客户端侧定位加密逻辑。通过Frida Hook对应的加密函数成功在内存里拿到了解密后的完整数据确认包含通讯录、短信内容、设备位置和安装应用列表。除数据回传外样本还维持着一个“心跳”机制每5分钟向服务器上报一次设备在线状态同时等待指令。这种心跳机制是远控木马的经典设计既能让服务器感知受害者设备是否在线也能用来接收新的指令下发。3.3 关键代码逆向关联回到静态代码层面我在jadx里继续追踪上传数据的逻辑发现数据组装是在一个叫DataCollector.smali的类里完成的这个类的命名已经非常直白。加密部分调用了Cipher类采用AES算法密钥硬编码在了native层的so文件里——这也是很多恶意样本的选择把密钥放在native层增加静态分析的难度。不过在实际分析时只要动态运行时Hook住加解密函数密钥就可以直接从内存中提取出来。继续追查so文件里的实现发现它还包含一个名为check_root的导出函数作用是检测设备是否已Root。如果检测到Root环境恶意样本会主动降低部分敏感行为频率降低被安全软件发现的风险。这个细节说明样本作者对安全对抗有清晰认知属于比较专业的恶意程序不是那种一句脚本就能写出来的垃圾木马。4. 全场景防护方案4.1 个人用户防护清单针对这类恶意样本个人用户最需要做的是防患于未然。我的第一条建议非常直接应用只从手机厂商官方应用商店或知名应用市场下载不要轻信网页弹窗、短信链接、微信群里的APK安装包。这类“天眼查询系统”式命名的恶意应用绝大多数流通于没有审核机制或审核宽松的非官方渠道只要守住了下载来源这个入口至少有八成的风险可以被挡在门外。第二点是权限审查习惯。每次安装应用时系统都会列出应用申请的权限清单花10秒钟看一下——一个查询工具申请读取通讯录、短信、定位、录音权限这本身就是一个巨大的危险信号。建议在系统设置里周期性检查已安装应用的权限授权情况清理掉那些不常用却拥有高权限的应用。第三点是运行环境的识别。这类“查询系统”名字里带着明显的“万能工具”色彩事实上越是宣称什么都能查的应用越要警惕。正规服务不会用一个明显不具备资质的小工具来承载核心功能。如果你的手机突然频繁弹出广告、电池掉电明显变快、流量消耗异常增加可以进入应用管理按安装时间排序把近期安装的可疑应用卸载掉。系统更新也值得重视。厂商推送的季度安全更新里通常包含了对已知恶意应用签名的封堵保持系统版本最新可以大幅降低中招概率。设备Root这件事也需要谨慎Root后的设备等于把系统最高权限交到了每个应用面前恶意样本在Root环境下能做的事情会多一个数量级。我的原则是日常使用的手机保持官方原厂状态永远不要为了“更好的控制感”牺牲安全性。4.2 企业移动端安全基线企业场景下个人层面的防护远远不够需要在移动端安全建设上做体系化布局。首要是移动设备管理MDM系统的落地通过MDM统一管理企业配发的所有移动终端做应用白名单控制默认禁止安装非白名单应用。这样即使有员工下载了“天眼查询系统”这类恶意APK安装这一步就会被系统拦截。第二层是移动威胁防御MTD产品这类产品会在设备端实时监测应用的异常行为包括权限滥用、恶意流量通信、可疑进程行为等。当某个应用在后台频繁读取通讯录并尝试外传时MTD会实时告警并阻断通信。这类产品对“天眼查询系统”这种恶意行为的识别率很高因为它的行为特征非常典型——启动后短时间内连续读取敏感数据、连接可疑IP、心跳通信。第三层是网络侧的访问控制。企业出口网关需要具备对恶意IP和域名的检测能力当终端试图连接已知恶意服务器时在网络层直接阻断。同时建议企业内部DNS启用安全过滤防止终端通过域名解析的方式连接到恶意基础设施。在实际防守中我见到过不少案例终端已经中了类似木马但因为网络侧的安全设备检测到异常流量并及时阻断恶意行为始终没能完成数据回传这样就为后续处置争取了非常宝贵的时间窗口。4.3 开发者自查与合规建议还有一类相关人群容易被忽略——应用开发者。如果你是安卓开发者无论写的是正规应用还是内部工具都建议在开发流程里加入安全自查的环节。我见过不少开发者为了图方便在自己的应用里申请了一堆用不上的权限这本身就是一种潜在风险。如果应用被第三方恶意打包器二次打包原来的权限机制还可能成为恶意代码的放大器。开发侧具体能做几件事做一个最小权限原则的自检清单逐项核对每个申请的权限是否真的有对应功能在使用发布前用在线病毒检测平台对APK做一次多引擎扫描开启代码混淆提升被反向分析的门槛。特别要提醒的是如果开发的应用需要在非官方渠道分发最好加上签名校验和服务端接口鉴权防止安装包被恶意篡改后重新签名并大量传播。合规层面国内个人隐私保护相关法规已经明确要求应用收集个人信息必须坚持最小必要原则超范围收集本身就是违规行为。“天眼查询系统”这种一次性把通讯录、短信、定位全都要走的做法不仅黑产背景浓厚站在合规角度也已经是严重越界正规应用绝对不应该这样设计。5. 研判结论与后续处置5.1 样本定性总结综合静态分析和动态监控的结果可以给“天眼查询系统”下一个清晰的定论这是一个高度专业化的安卓远控木马集隐私窃取、短信劫持、指令执行、恶意推广等多种功能于一体整体代码不大但功能密集且在模拟器检测、Root环境感知、native层加密对抗等多个维度都有意识做了加固处理。它不是普通小毛贼能写出来的东西背后应该是一个有组织的黑产团伙在运作基础设施更换频繁投放渠道覆盖面广。对这种样本的正确态度是不要抱有任何侥幸心理不要以为“只要我不输入账号密码就没事”。恶意程序根本不挑受害者只要你的手机上有任何隐私数据包括通讯录、短信、地理位置、应用账号它都会贪婪地收走。及时发现、及时处置才是唯一出路。5.2 遇到样本后的应急处置参考如果你的手机已经安装了可疑应用并且出现了前述异常表现可以参考以下几个处置步骤第一时间开启飞行模式切断网络阻止隐私数据继续外传进入设置-应用管理尝试卸载这个可疑应用如果卸载按钮置灰说明它激活了设备管理器需要先进入“设备管理”列表把它取消激活如果因为Root或加固原因无法正常卸载优先备份个人重要资料然后恢复出厂设置。恢复后建议批量修改所有相关账号的密码。关于恶意样本的上报发现可疑APK后可以提交到在线病毒分析平台做多引擎扫描也可以直接提交给手机厂商的安全团队。上报时尽量保留完整的样本文件和网络抓包数据这些技术细节对追踪同源木马、封堵C2服务器都有实际价值。5.3 后续还可以如何扩展检测思路对于一个安全研究者或爱好者来说拿到这类样本后还有不少可以继续深挖的方向。一个是做同源样本追踪这个样本的C2服务器、加密密钥、签名证书都可以作为关联指标在威胁情报平台上追溯同源家族的其它样本往往能找到同一团伙的其它恶意工具。另一个方向是逆向它的指令协议完整还原远控指令集相当于掌握了一套完整的“恶意识别规则”可以直接用于生产环境的检测规则编写。我个人在实际分析中还习惯做一件事——把每次分析的样本特征指标整理成一份本地知识库包括包名、签名指纹、C2地址、权限组合、行为特征。时间久了这份知识库就像一个“恶意样本词典”再遇到新样本时先本地比对一遍往往能快速定位到已知家族分析效率会有明显提升。这个习惯也推荐给长期做移动安全方向的朋友积累是这一行最实在的增长方式。
