Anthropic-Cybersecurity-Skills 中的 Android APK 恶意软件静态分析：基于 androguard 的完整流水线与源码详解

Anthropic-Cybersecurity-Skills 中的 Android APK 恶意软件静态分析：基于 androguard 的完整流水线与源码详解

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

本文围绕 SKILL.md 展开，讲解如何在 Anthropic-Cybersecurity-Skills 仓库的analyzing-android-malware-with-apktool技能下，对可疑 APK 执行"不执行样本"的静态分析：从权限风险评级、Manifest 组件枚举、可疑 API 调用扫描，到字符串 IOC 提取与混淆检测。读完本文，你可以直接运行该技能自带的分析脚本 agent.py，理解其内部 20 项危险权限清单、14 条可疑 API 模式、风险评分模型与 MITRE ATT&CK Mobile 技术映射的完整实现逻辑。

一、技能定位：为什么 APK 静态分析适合"静态优先"

该技能属于仓库 817 个安全技能中的 malware-analysis（恶意软件分析）子域，其 frontmatter 描述（见 SKILL.md 头部元数据）明确了分析目标：

Perform static analysis of Android APK malware using apktool for resource decompilation, jadx for Java source recovery, and androguard for manifest inspection, dangerous permission-combination detection, and identification of obfuscated code, dynamic code loading, and reflection-based API calls.

可以概括为三层工具分工：

从源码结构看，agent.py仅导入 androguard（APK、DEX、AnalyzeAPK），说明该技能的自动化流水线完全建立在 androguard 之上，apktool/jadx 作为 Prerequisites 中列出的外部工具，服务于人工解包与深度逆向场景。这种"程序化分析为主、反编译工具为辅"的组合，可以在不执行样本的前提下完成对可疑 APK 的结构化分诊，并进一步沉淀为移动恶意软件检测规则。

技能适用的典型场景（继承自原文档 When to Use 一节）：

• 安全事件调查中需要分析 Android 恶意软件样本；
• 需要为移动端检测体系编写检测规则或威胁狩猎查询；
• SOC 分析师需要针对此类分析的结构化操作规程；
• 校验安全监控对相关攻击技术（ATT&CK Mobile）的覆盖情况。

二、前置条件与环境准备

原文档给出的 Prerequisites 与 api-reference.md 的 Dependencies 一节共同确定了运行前提：

• Python 3.9+，并安装androguard >= 3.4.0（安装命令pip install androguard；脚本在未安装时会返回{"error": "androguard not installed: pip install androguard"}，见 agent.py 的full_analysis()入口检查）；
• apktool（用于资源反编译）；
• jadx（用于 Java 源码还原，可选）；
• 隔离分析环境（虚拟机或沙箱）——分析未知 APK 时必须隔离；
• 待分析的样本 APK 文件。

脚本顶部对 androguard 采用try/except ImportError兜底（导入失败时将APK = None），使得脚本在没有依赖的环境中也能被解析、只在真正分析时报错，这一设计降低了在受限环境中误用脚本导致崩溃的风险。

三、CLI 用法与总体分析流程

api-reference.md 给出的命令行接口如下：

python agent.py sample.apk permissions # 仅权限分析 python agent.py sample.apk manifest # 仅 Manifest 组件提取 python agent.py sample.apk apis # 仅可疑 API 扫描 python agent.py sample.apk strings # 仅字符串/IOC 提取 python agent.py sample.apk full # 完整恶意软件评估 python agent.py sample.apk # 缺省即 full 分析

参数解析逻辑位于 agent.py 的main()：full或缺省命令走full_analysis()；其余子命令直接调用AnalyzeAPK()并分别路由到analyze_permissions/analyze_manifest/scan_suspicious_apis/extract_strings。所有结果统一以json.dumps(result, indent=2, default=str)输出 JSON。

原文档 Steps 一节定义的七步流程，与脚本函数的一一对应关系是：

1. 用 androguard 解析 APK、提取 Manifest 元数据 →AnalyzeAPK()+analyze_manifest()
2. 枚举请求权限并标记危险组合 →analyze_permissions()
3. 列出 activities / services / receivers / providers →analyze_manifest()
4. 扫描可疑 API 调用（反射、加密、短信、电话）→scan_suspicious_apis()
5. 检测动态代码加载模式（DexClassLoader、Runtime.exec）→ 同样由scan_suspicious_apis()的模式表覆盖
6. 从字符串提取硬编码 URL、IP 与 C2 指标 →extract_strings()
7. 生成含 MITRE ATT&CK Mobile 映射的风险评估报告 →full_analysis()末尾的mitre_techniques组装

四、权限分析：20 项危险权限与四级风险评级

analyze_permissions()（agent.py）调用 androguard 的apk.get_permissions()取出全部请求权限，与DANGEROUS_PERMISSIONS常量（L17-L28）求交集。完整清单覆盖六类恶意行为：

注意BIND_ACCESSIBILITY_SERVICE与BIND_DEVICE_ADMIN这两项：它们不是普通 App 直接申请、而是通过绑定被授予的特权权限，在恶意软件中分别对应无障碍服务劫持与设备管理锁定（勒索型恶意软件常用DevicePolicyManager.lockNow锁屏勒索）。

权限风险评级规则（与 api-reference.md 的 Risk Scoring 描述一致）：

CRITICAL 危险权限数 >= 8 HIGH 危险权限数 >= 5 MEDIUM 危险权限数 >= 2 LOW 危险权限数 < 2

返回结构包含total_permissions、permissions（全量）、dangerous_permissions（命中项）、dangerous_count与permission_risk五个字段，可直接作为检测规则的特征输入。

五、Manifest 组件提取：四类组件与版本信息

analyze_manifest()（L61-L82）调用apk.get_activities()、get_services()、get_receivers()、get_providers()四类组件枚举，同时输出：

• package_name、app_name：包名与应用名（伪装识别的第一手线索）；
• version_name、version_code：版本信息；
• min_sdk、target_sdk：目标 SDK 级别——过低的 targetSdk 常伴随弱化的系统安全约束，可作为风险信号；
• 四类组件的完整列表及各自计数。

组件计数本身也参与后文的风险映射：源码中当service_count > 5时即标记一条 T1418（Software Discovery）技术，因为服务组件异常膨胀往往意味着内置后台驻留模块。

六、可疑 API 扫描：14 条 DEX 级模式与交叉引用

scan_suspicious_apis()（L85-L101）是脚本中最具检测价值的部分。它遍历SUSPICIOUS_API_PATTERNS（L30-L45）中 14 条 Dalvik 内部名模式，通过dx.find_methods(classname, methodname)定位方法对象，再用method.get_xref_from()取交叉引用——只有存在调用方（xrefs 非空）的方法才会计入发现项，这有效过滤了"库中定义了但从未被调用"的噪声。

14 条模式按攻击意图分组：

每条命中的输出结构为{"api": 模式, "callers": 调用方数量, "first_caller_class": 首个调用方类名}，其中first_caller_class可直接指引分析师在 jadx 中跳转查看具体调用上下文。

七、字符串与 IOC 提取：URL、外网 IP 与 Base64 候选

extract_strings()（L104-L131）遍历dx.get_strings()的全部 DEX 字符串，用三条正则做提取：

url_pattern = re.compile(r'https?://[\w\-._~:/?#\[\]@!$&\'()*+,;=]+', re.IGNORECASE) ip_pattern = re.compile(r'\b(?:\d{1,3}\.){3}\d{1,3}\b') b64_pattern = re.compile(r'[A-Za-z0-9+/]{30,}={0,2}')

实现上有三个值得注意的细节：

1. 内网 IP 过滤：private_ips = {"10.", "192.168.", "172.16.", "127.0."}前缀匹配剔除私网地址，避免把开发期硬编码的本地地址误报为 C2；
2. 结果截断：urls最多保留 30 条、external_ips最多 20 条、每条字符串最多取 5 个 base64 候选且总计 10 条，控制报告体积；
3. Base64 候选的意义：30 字符以上的 base64 片段常是 XOR/Base64 双层编码后的 C2 域名或配置数据，属于人工复核的高优先级线索，而非确定性 IOC。

返回字段urls、external_ips、suspicious_base64及对应计数，与external_ip_count直接进入风险评分（每条外网 IP 计 5 分，上限 15 分）。

八、混淆检测：单字母类、Multi-DEX 与原生库

detect_obfuscation()（L134-L158）检查三类混淆指标：

• 单字母类名（ProGuard/R8 混淆特征）：遍历dx.get_classes()，将类名按.分段，只要任一段为单个字母即计入；超过 10 个才标记single_letter_classes（小阈值会误报正常代码，从源码结构看这是一个经验性阈值）；
• Multi-DEX：apk.get_files()中.dex文件数大于 1 时标记multi_dex——分片既可能是体积原因，也是恶意软件拆分逻辑段的常见做法；
• 原生库：存在任一.so即列出（最多 10 个）标记native_libraries，提示后续需要用 Ghidra/IDA 做 native 层分析。

只要任一指标命中，likely_obfuscation置真，风险评分即增加 15 分。

九、风险评分模型与 ATT&CK Mobile 技术映射

full_analysis()（L161-L198）汇总五个模块并计算 0–100 分的风险分，评分规则与 api-reference.md 的 Risk Scoring 表一致：

risk_score += min(perm_analysis["dangerous_count"] * 8, 40) risk_score += min(len(suspicious_apis) * 10, 30) risk_score += min(strings["external_ip_count"] * 5, 15) risk_score += 15 if obfuscation["likely_obfuscated"] else 0 risk_score = min(risk_score, 100)

对应等级：CRITICAL >= 70、HIGH >= 50、MEDIUM >= 25、其余LOW。

报告的mitre_techniques字段按静态证据映射 ATT&CK Mobile 技术，映射条件全部来自已提取的结构化证据：

这与 SKILL.md frontmatter 中声明的mitre_attack映射（T1406、T1407、T1626.001、T1655.001、T1521.001，均属 Mobile 矩阵技术）形成两层视角：frontmatter 面向技能的框架级覆盖声明，mitre_techniques面向单个样本的证据级判定。NIST CSF 侧则映射了DE.AE-02（分析事件）、RS.AN-03（分析工件）、ID.RA-01（业务资产目录）与DE.CM-01（网络连接监控）四个类目，说明该技能同时服务于"事件响应—工件分析—资产画像—通信监控"的完整闭环。

十、预期输出与实战工作流

按原文档 Expected Output 一节，一次完整分析产出：

• JSON 报告：含manifest（组件与版本）、permissions（权限风险）、suspicious_apis（最多 20 条）、strings（IOC 候选）、obfuscation（混淆指标）、risk_score/risk_level与mitre_techniques；
• 提取的字符串与潜在 IOC：URL、外网 IP、base64 候选片段。

推荐的实战工作流（结合七步流程与工具分工）：

1. python agent.py sample.apk full得到总体风险分与报告骨架；
2. risk_level为 HIGH/CRITICAL 时，优先核查suspicious_apis中callers多的条目，用 jadx 打开对应first_caller_class查看调用链；
3. 对suspicious_base64与外网 IP 做解码/域名情报富化，确认 C2；
4. 若检出native_libraries，转入 Ghidra 等工具做 native 层分析；
5. 将external_ips、URL 与包名沉淀为检测规则（YARA / 移动端 EDR 规则）的 IOC 输入。

十一、文件索引与延伸阅读

本技能在仓库中的完整文件构成：

• SKILL.md：技能定义（frontmatter 框架映射 + 七步流程 + 预期输出）；
• references/api-reference.md：androguard API 方法表、CLI 用法与评分规则说明；
• scripts/agent.py：可直接运行的静态分析脚本；
• LICENSE：Apache-2.0 许可声明。

该技能遵循 agentskills.io 开放标准（见仓库 README.md 的整体说明），可在 Claude Code、GitHub Copilot、Codex CLI、Cursor、Gemini CLI 等 26+ 平台中作为技能被 AI Agent 加载，由 Agent 按照本文所述流程自主完成可疑 APK 的静态分诊。

最后需要强调的适用限制：本技能是纯静态分析手段，对重度加壳/加密 DEX 的样本，字符串与 API 扫描的检出率会显著下降（混淆检测指标命中即是信号）；且脚本中的技术映射、评分权重均为静态启发式规则，输出应作为分诊优先级依据而非最终定性结论。涉及样本处理时务必在隔离环境操作，并仅用于授权的安全研究与防御场景。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills