日本国家级应急响应机构的职能由 NISC 与 JPCERT/CC 共同负责。NISC 与 JPCERT/CC 负责内容的区分是：NISC 主要作为日本政府单位的应急响应机构，主要应对政府部门的安全事件；其余私营部门由 NISC 与 JPCERT/CC 共同管辖，主要由 JPCERT/CC 负责。 Avenger，公众号：威胁棱镜我们能从日本保障东京奥运会网络安全工作中学到什么？
在之前的文章中介绍过日本国家网络安全事件应对与战略研究中心（NISC），感兴趣的可以移步查看。本次介绍的是日本另一个国家级应急响应机构 JPCERT/CC 在恶意软件分析领域内的工作，来看看该组织为推进自动化恶意软件分析运营做出了哪些探索与实践。
恶意软件 C&C 服务器监控系统
在“Lucky Visitor 诈骗”案例中，攻击者通过 C&C 服务器向被篡改的 PHP 网站发送命令，将访问者重定向到诈骗网站。C&C 服务器下发的重定向 URL 会定期更改，持续监控 C&C 服务器即可持续跟踪重定向 URL。
为了应对这种攻击，JPCERT/CC 自动化了整个处理流程，如下所示：
整个系统部署在 AWS 上，Lambda 扫描 C&C 服务器并将结果通过 GitHub Action 发送到 Google Safe Browsing。
对外也公开了重定向 URL 的列表
https://github.com/JPCERTCC/Lucky-Visitor-Scam-IoC
Cobalt Strike Beacons 分析系统
恶意软件分析人员会搜寻大量的样本，但又不能手动一一进行分析。JPCERT/CC 通过 VirusTotal 获取有关 C&C 服务器的信息，再自动采集 Cobalt Strike Beacons 样本进行分析获取配置信息。
整个系统部署在 AWS 上，除了自动流程外还准备了手动分析的 API 接口。当发现未知的 C&C 服务器时，就可以手动提供 URL 在不下载样本的情况下调查 C&C 服务器。
对外也公开了 Cobalt Strike Beacon 的信息
https://github.com/JPCERTCC/CobaltStrike-Config
Yara CI/CD 系统
手动创建 Yara 规则较为耗时，自动为具有特定模式的恶意软件生成 Yara 规则是极为必要的。在“HUI Loader”的案例中，加载程序容易找到，但用于加载的编码后的恶意软件很难找到。由于加载程序的编码算法是已知的，可以通过 Yara 规则来检测使用该编码的恶意软件。
整个系统部署在 AWS 上，自动通过 VirusTotal 获取样本并对其进行分析，生成 Yara 规则后再送回 VirusTotal 收集新的样本。
对外也公开了 HUI Loader 的信息
https://github.com/JPCERTCC/HUILoader-research
云端分析系统
将哈希值发送到分析系统，通过 VirusTotal 来获取恶意软件，再使用 Yara 等分析工具进行扫描：
各种渠道来源披露的威胁信息非常多，找到公开披露的信息与组织内收集到的信息是否存在关联是十分重要的。部分结果如下所示：
整个系统部署在 AWS 上，可自动化处理分析来自博客与 Twitter 上披露的恶意软件。此外，也可以通过 API 网关接收浏览器插件发送的哈希值，触发 Batch 对恶意软件进行分析。
云端内存取证系统
在进行安全事件调查时，通常需要进行设备取证。如果需要对大量设备同时进行取证时，传统的方式费时费力，因此构建云上内存取证系统十分有必要。
内存镜像首先保存在 S3 中，需要时触发 Batch 启动 Docker，再由 Volatility 进行分析。部分结果如下所示：
总结
随着每天新增的恶意软件越来越多，自动化运营的重要性也在不断彰显。为了更好地推进业务目标，使用云或者其他技术方式都是手段，构建更加自动化、更加可运营的恶意软件分析流水线是大家共同的目标。他山之石，可以攻玉。
点击阅读原文即可查看 JPCERT/CC 原始文章。
原文始发于微信公众号（威胁棱镜）：JPCERT/CC 如何在云端自动化恶意软件分析
