分类目录归档：集跬步

云安全

云上攻防：Red Teaming for Cloud

前言

Red Team的概念最早来源于20世纪60年年代的美国军方，指的是一个通过承担对抗性⻆角⾊色来挑战组织以 提⾼高其有效性的独⽴立的团体叫做Red Team。 国外科技企业一般定义Red Team的目标有以下好几个：

  • 学习和利用已知真实攻击者的TTPs来用于攻击；
  • 评估现有防御能力的有效性以及识别防御体系的弱点并提出具体的应对方案；
  • 利用真实有效的模拟攻击来评估因为安全问题所造成的潜在的业务影响，为上层管理者提供有效的数据来量化和衡量安全投入的ROI。

Red Teaming行动的常见方法有以下几种：

  • 模拟直接威胁者：根据特定的威胁情报来模拟攻击者，所谓“以情报驱动的Red Teaming行动”，目前深受国际主流互联网企业的Red Team团队的青睐，例如针对某些特定行业或者国家的APT组织的TTPs的模拟；
  • 模拟已知威胁者：根据已披露的APT组织的TTPs来模拟攻击者，例如利用ATT&CK来规划和映射Red Teaming行动所需的TTPs；
  • 模拟未知威胁者：根据真实入侵的各个阶段收集到的具体目标信息实时地规划攻击路径从而模拟攻击者。

这三种方法其实应该算是Red Teaming行动在企业处于不同的威胁阶段时应该采用的不同方法，个人以为前两种应该作为甲方企业自身Red Team的主要工作方向，第三种可作为前两种的进阶补充或者乙方Red Teaming服务的工作重心。具体而言，第一种方法主要是模拟直接威胁者，通过威胁情报提前发现直接威胁者的TTPs并加以模拟来检测防守团队应对直接威胁的防御能力，这是Red Teaming行动的基本目标；第二种方法主要是模拟已知威胁者，通过模拟目前所有已知的攻击组织的TTPs来全面而系统地识别防守团队的防御弱点并帮助其提高检测所有已知威胁的覆盖率，这是Red Teaming行动的主要目标；第三种方法主要是模拟未知威胁者，通过模拟真实黑客的潜在入侵行为来检测当前企业面对未知威胁的防御能力，这是Red Teaming的进阶目标。 Red Teaming for Cloud，只是上面介绍的Red Team建设的一个子集，这篇文章重点分享一下在公有云环境下进行Red Teaming行动的一些个人经历与思考。

团队建设

企业在想要开始Red Teaming行动之前，需要构建一个可信、可管理、可审计的Red Team团队，具体包括：

方法论

  • 目标范围：场景化的具体的行动目标（如窃取客户财务数据，访问CEO的邮件，控制云服务管理服务器，控制云上租户的云资源等），攻击范围，授权许可，行动时间，行动约束（Rules of Engagement）
  • 情资搜集：威胁情报（0day漏洞研究与Nday漏洞利用、最新攻击手法等）和目标资产（IP、域名、员工信息、初始入口等）的收集
  • 行动计划：攻击计划与TTPs准备
  • 行动执行：实施攻击
  • 记录报告：文档记录，行动报告

行动流程

  • 攻击计划：
    • 行动准则（授权与禁止行为，授权范围，限制条款等）
    • 风险管理（提前识别和管理行动过程中的各种潜在风险）
    • 行动计划（威胁情报，ATT&CK TTPs等）
    • 报备与授权流程
    • 行动终止流程
    • 行动成本与预算
  • 攻击执行：
    • 备案的时间区间内
    • 备案的目标范围内
    • 备案的攻击IP与网络环境
  • 攻击完成：
    • 恢复所有修改
    • 移除所有payload和backdoor
    • 移除所有持久化控制
    • 关闭所有C2通道
    • 提交攻击报告与改进建议（执行总结，方法论与目标，攻击场景与范围，攻击过程与时间线，关键发现与改进建议）
    • 开始复盘会议（技术层面）

运营管理

  • 行为管理：
    • 权限管理
    • 政策控制
    • 物理控制
    • 软件控制
    • 内部共享资料库管理
  • 数据管理：
    • 事前情资数据
    • 攻击行为记录
    • 操作日志
    • 自动化数据收集与日志
    • 攻击行为截图
    • 事后攻击数据（攻击报告，数据归档，内部报告分发等）

实践

工欲善其事，必先利其器。一个好的Red Team，绝不是什么技术高级就搞什么，而是一定要有明确的场景化的目标和思路清晰的攻击框架来指导我们怎么一步步去达成我们的目标，比如：ATT&CK for Cloud。
 attack-for-cloud

以下是常见的Red Teaming for Cloud的攻击场景（以AWS，Azure，GCP为例）：

一、利用公有云上租户的不安全的应用与服务配置为突破口

场景一：云服务认证Key泄漏（如AWS AK/SK或者Security Token等）

攻击难度：低

攻击路径：云服务认证Key -> 云服务公开API/SDK -> 云服务资源访问/控制

利用方式：

  • Github仓库配置不当
  • 云架构中的密码重用
  • 针对云租户账号密码的社工攻击（如AWS Credential Harvesting钓鱼攻击）
  • 云主机中Web应用的漏洞（SSRF，RCE，本地文件读取等漏洞）
  • 公共的存储桶
  • 信任的关联第三方数据泄露
  • 硬编码在网页或移动APP中的AK/SK。

相关参考：

场景二：云上租户的云服务不安全配置

攻击难度：低

攻击路径：公共访问的云存储桶 -> 敏感凭证 ->  云服务资源访问/控制

利用方式：公共访问的云存储桶爆破

相关参考：

场景三：云主机中web应用自身漏洞

攻击难度：中

攻击路径：

  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS SSM -> RCE
  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS Lambda -> RCE
  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS S3 -> 信息泄漏
  • RCE -> EC2 Metadata API -> IAM临时Security Token -> AWS EC2/S3/Lambda
  • RCE -> EC2 Metadata API -> EC2 Userdata -> 敏感凭证 ->  其他EC2或者云服务
利用方式：Web应用漏洞（如SSRF/XXE/RCE等）
相关参考：

二、利用公有云本身的服务（IaaS，PaaS，SaaS）的自身问题为突破口

场景一：云服务自身功能导致代码执行
攻击难度：低
攻击路径：云服务账号AK/SK -> 云服务功能（AWS SSM/Lambda/EC2 Instance Connect）-> RCE
利用方式：
  • 外部泄漏的云服务账号AK/SK（Github，Public S3 Buckets，硬编码在网页或移动APP中的AK/SK等）
  • EC2云上应用SSRF漏洞配合AWS Metadata API
相关参考：
场景二：云服务的公开API利用
攻击难度：低
攻击路径：云服务账号AK/SK -> 云服务公开API -> 云服务资源调用（OS镜像，容器镜像，存储桶，数据库，Userdata等）-> 敏感信息泄露（数据，凭据等）
利用方式：云服务公开API的熟悉和利用，如AWS CLI/AWS SDK
相关参考：
场景三：云服务第三方软件漏洞利用
攻击难度：中
攻击路径：第三方软件漏洞 -> 使用该软件的云服务 -> 云服务系统/平台 -> 其他租户数据
利用方式：
  • 收集云服务利用的第三方软件列表与相应的版本信息，如MySQL，ElasticSearch，Docker，K8S等
  • 第三方软件0day研究和Nday的收集与利用
相关参考：
场景四：云服务私有或者公开API漏洞挖掘与利用
攻击难度：中-高
攻击路径：云主机中应用SSRF漏洞或者云服务账号AK/SK -> 云服务私有/公开API漏洞 -> RCE/信息泄露
利用方式：
  • 云服务私有API寻找与测试（云服务Web请求分析，云服务SDK或者离线工具分析等）
  • 云服务公开API漏洞研究（输入输出校验，认证与鉴权绕过等）
  • 云主机中的应用的SSRF漏洞
相关参考：
场景五：容器逃逸
攻击难度：中-高
攻击路径：共享容器 -> 宿主机 -> 其他租户容器
利用方式：
  • 容器逃逸漏洞
  • 宿主机目录挂载（/var/run/docker.sock）
  • 特权容器
  • Kubernetes安全
相关参考：
场景六：虚拟机逃逸
攻击难度：高
攻击路径：弹性云主机 ->  宿主机 -> 同一宿主机上其他弹性云主机
利用方式：虚拟机逃逸漏洞
相关参考：
场景七：云服务管理面网络入侵
攻击难度：高
攻击路径：公有云厂商办公网/DMZ区域 -> 公有云员工权限 -> 公有云管理面网络 -> 公有云生产网
利用方式：
  • 企业办公网/DMZ区域入口（钓鱼，OWA，VPN，WiFi，远程办公，物理入侵，DMZ区域对外应用漏洞等）
  • 传统的内网渗透入侵手法

案例

下面是一些AWS/Azure/GCP相关的攻防案例：

AWS

Azure

GCP

General

工具

以下是一些在云上Red Teaming时会用到的工具：

安全建设

企业安全建设的体系思考与落地实践之二

前言

不知不觉中距离上一次发文已经四个多月了，这四个月不仅我个人的生活和工作发生了很多变化，我想大部分人的生活因为这场突如其来的疫情也发生了巨大变化。不过，这个世界每天都在“悄无声息”地变化着，而作为一个“有志的技术青年”，“不悲观、不放弃、勤思考、擅质疑，多实践，频总结”，并积极乐观的生活与工作着才更加重要。

今天这篇文章没有太多的技术细节，也可能会让你觉得很枯燥，甚至连文章的标题我都懒得起（只是临时征用了一个之前的文章标题《企业安全建设的体系思考与落地实践》并“敷衍”地加了个“二”，其实二者关系并不大），但是我觉得如果你实在无聊也可以读一读，或许给你些许启发。

思考

在讲述企业安全建设的演讲PPT和书籍中，我们经常会见到各式各样的建设体系和分类，包括我自己写的这一篇《企业安全建设的体系思考与落地实践》，初看觉得有点道理，但是细想下来又让人有一种“食之无味弃之可惜”甚至是“言之凿凿有何卵用”的感觉。

那么怎么来分析和思考这个问题呢？一种最为简单的方法就是“5W（5 Why）根因分析法”，即深入地渐进式地问自己至少5个“为什么”从而挖掘问题的根本原因。

“为什么看似有道理而实际没卵用？”因为其过于强调解决安全体系建设中遇到的共性问题，而忽略不同企业间的差异性问题。

“为什么重共性、轻异性会导致这个结果呢？”因为大部分企业的安全建设真正的难点不在于共性问题的解决而在于怎么寻找解决差异性问题的思路和方法。

“为什么差异性的问题的解决才是企业安全建设的真正难点？”因为这种差异性问题是由不同企业的发展阶段、业务形式、人员管理等多方面因素所造成的，且没有办法在外面直接找到解决这些差异性问题的安全建设方法。

“为什么企业的发展阶段、业务形式、人员管理等多方面因素会造成这些差异性问题？”因为企业的发展阶段决定了安全在企业发展中所处的地位和价值的不同，业务形式决定了企业面临的安全风险的不同，人员管理决定了企业对安全的认知能力的不同。

根据以上一系列的自问自答，我们似乎找到了产生这类感觉的根本原因是由企业的“发展阶段，业务形式，人员管理”的不同所造成的。那么下一个很自然的问题，怎么才能解决因为这些不同所造成的安全建设过程中的困境呢？笔者认为一种方法就是“对症下药”，将安全体系建设根据企业的发展阶段融入公司业务发展和人员管理之中。

实践

本节笔者将试图以自己当前阶段有限的知识和经验来谈谈具体怎样“对症下药”（注：随着笔者自身认知的提升，未来可能会有更有效的“药”）。既然是“对症”，首先就得知道当前企业具体处于什么阶段。笔者将分别针对以下三种阶段的企业聊聊怎么“下药”。

小型创业公司

这类企业的业务形式往往比较单一，可能是某个特别细分的领域；人员管理相对简单，一般都在50人以下。针对这类企业，谈复杂成熟的体系化安全建设还为时尚早，但是这并不意味着安全不重要，相反这正是安全体系建设的早期阶段，投入少见效快。这时，安全建设的重点应该是保证业务的可用性和完整性。企业的大部分网络资产是员工的办公电脑以及公有云服务，因此提高员工的安全意识以及利用好公有云服务提供商的安全解决方案（例如：WAF，Anti-DDOS，主机防护，堡垒机等）对于企业的安全能力建设必然会事半功倍。因此，周期性的安全意识培训和宣讲，标准化的业务上云流程（资源申请，配置管理，云上安全解决方案等）将是小型创业企业的安全建设的“良药”。

中型传统公司

这类企业一般在某个行业里已经深耕了多年，业务形式比较确定且变化少；人员相对较多，管理也比较稳定。由于企业已经运行了多年人员管理较为固化加之业务变化少，很容易造成其对于安全的体系建设的内在动力不足，更多的驱动力是来自于外在的监管要求（比如网络安全法，等保，GDPR，以及各种行业合规要求等）和安全事件的发生。对于这类企业，安全建设的重点应该以外部监管的要求为支点，以实际安全的落地要求为抓手，以发生的安全事件为“契机”，循序渐进地推动企业往体系化的安全建设的方向去走，将安全的防御策略融入到业务场景帮助业务解决实际运营中遇到的各种安全风险（如：法律法规对隐私数据保护的要求，行业合规对客户数据处理的规定等），并积极协助和推动业务系统往更加安全的方向迭代和升级（如：利用传统企业往IT化、云化的方向演进的趋势，积极融入安全的建设思想，系统性地解决业务系统升级过程中的安全痛点）。同时，通过外部的要求和内部的迭代演进，把安全的认知意识通过已有的成熟的人员管理体系（如：内部培训，绩效考核，工作方法，奖惩制度等）逐步固化到每一个企业员工的日常工作和思考方式中。这个阶段的企业，切忌不可盲目跟风当前“最流行”的安全概念，如果连最基本的日志都收集不全、边界安全都没完善，还谈什么威胁情报、Anti-APT、Red Teaming、零信任之类的，此时这些不过是“镜花水月”、“空中楼阁”罢了。

大型互联网公司

这类公司的业务繁杂且变化迅速；人员繁多且管理复杂。其一般已经具备了相应的的安全防御能力，安全体系建设也已经基本完成。这些公司最大的问题是已有的安全体系无法快递地适配或者说是跟进业务的发展，这就造成快速发展的业务与缓慢跟进的安全建设之间的矛盾。笔者认为，解决这种矛盾的方法之一就是安全建设融入业务发展，业务发展驱动人员管理，人员管理促进安全建设。

640

安全建设融入业务发展

我们常常看到各种安全建设体系里提到很多细分领域如：“安全治理”、“安全合规”、“数据安全”、“SDL”、“基础安全”、“内网安全”、“应用安全”、“安全运营”、“云安全”等等，每个领域往往都是各自为政、单打独斗，相互之间也会彼此独立，却很少能看到如何将这些所谓的细分领域彼此关联并融入到具体业务发展中去。很多时候我们在谈论安全建设时很容易陷入脱离业务来谈安全的怪圈，没有真正地理解业务所面临的的安全困境和痛点，所以需要从“外挂式安全”变成真正的“原生式安全”。

所谓“原生式安全”，并不是什么新的概念，而是将安全建设伴随着业务发展的整个生命周期融入业务的产生、设计、上线、运营、迭代、下线等各个阶段之中，旨在让各个细分领域彼此关联形成一个互相联动的整体。

举个例子，一个新业务的发展往往经过以下流程：业务团队根据市场调研的结果挖掘出客户需求；研发团队根据需求设计并持续开发和交付相关的业务产品和支撑系统；运维团队维护和管理已交付的业务系统；运营团队从上线的业务系统中拉取并分析客户数据做持续运营。我们可以采取下面的方式将安全建设融入到业务发展的生命周期里。

一、安全合规和治理所制定的安全政策既要帮助业务团队确定需求的合规性，也要将各种安全政策和标准通过工具的形式融入到软件/系统开发的SDL流程中（如：CICD流水线），让研发团队在系统架构设计之初通过自动化工具即可了解所设计系统的潜在数据风险等级以及相应的标准化的数据处理方案（如：传输加密与否？存储加密与否？何种类型的加密算法？哪些可用的公共加密组件？哪些可用的专有敏感数据存储系统？等等）。

二、在编码阶段提供给研发团队默认安全配置的代码仓库模板和相应的缺省加固后的开发框架以及统一的认证、授权、密钥存储等公共安全系统或组件。

三、在测试阶段提供集成在流水线之中的动/静态安全测试工具。

四、在部署阶段采用自动化的方式申请资源（如：统一的经过安全加固后的操作系统或容器镜像等）和配置参数。

五、在上线阶段所有资源信息自动同步纳管CMDB并与HR系统中的员工（服务owner团队）联系方式关联。

经过上述方式，我们便可以将安全政策和标准融入业务威胁建模之中，公共安全组件和框架融入业务开发之中，安全测试融入业务测试之中，安全加固融入业务部署之中，安全监控和纳管融入业务上线之中，并最终形成一个标准的具备“原生式安全”的业务发展流程。

业务发展驱动人员管理

随着自带“原生式安全”属性的标准业务发展流程的成熟，必定会对人员的要求越来越高，那些安全意识薄弱的人员会被不断教育或者逐渐淘汰，人员的安全认知能力也会因为成熟的流程而逐渐被提升并固化到日常的工作生活之中，最后变成了每个人员的安全潜意识。

人员管理促进安全建设

当具备安全潜意识的人员越来越多，他们就有可能自主发现更多潜在的安全问题，并输出安全需求，从而促使安全建设的持续发展和迭代，形成一个良性的闭环。

后记

洋洋洒洒写了这么多，其实想表达的意思就是一句话：安全建设应该以“客户”为中心，从安全的受众出发，彼此融入，协同发展。

笔者的一直以来的安全观可以总结成以下几个词：原生（Security-native）、身份（Identity）、自动化（Automation）、情报驱动（Intelligence-driven）。

参考

安全建设

基于MITRE ATT&CK的Red Teaming行动实践

前言

如果要评选最近一年内国内信息安全圈最火的一个安全新名词，那一定是“MITRE ATT&CK”了。这个词在其被引入国内的那一刻起，就似乎备受青睐，常见于各种文章、PPT、演讲之中，大有赶超前几年的安全热词“威胁情报”之势。一时间造成了一种如果在2019年没听说过“MITRE ATT&CK”的安全从业人员不算是真正的业内人士的错觉。可是，物极必反，但凡被吹捧的越高往往跌的越惨，笔者私下里也在多个场合听到一些对“MITRE ATT&CK”被过度吹捧的反感言论，其实看待任何新鲜的事物和概念都需要冷静分析、客观思考、取其精华、去其糟粕，最后为我所用才是正道。

根据MITRE ATT&CK的官方描述，我们可以知道其是一个梳理攻击者的入侵行为（包括战术和技术）的知识库，其目的在于帮助防守方全面地了解和分析攻击者的TTPs。对于乙方安全公司，可以利用ATT&CK来开发各种安全产品或服务的威胁检测方法提高入侵检测的覆盖面；而对于甲方企业，则可以利用ATT&CK来设计各种威胁模型来检测与之对应的攻击手法，提高整体的防御检测的能力。

本文将探讨如何利用ATT&CK站在攻击者视角来组织和实践Red Teaming行动，更加有针对性的模拟真实世界的攻击者以达到“实战养兵”的目的。至于什么是Red Teaming，本文将不再赘述，具体可参阅笔者之前的文章《Red Team从0到1的实践与思考》。

规划

有效的Red Teaming行动是离不开充分的事前准备和行动规划的。那么如何利用Red Teaming行动来模拟真实攻击者呢？目前比较流行的方法有以下几种：

  • 模拟直接威胁者：根据特定的威胁情报来模拟攻击者，所谓“以情报驱动的Red Teaming行动”，目前深受国际主流互联网企业的Red Team团队的青睐，例如针对某些特定行业或者国家的APT组织的TTPs的模拟；

  • 模拟已知威胁者：根据已披露的APT组织的TTPs来模拟攻击者，例如利用MITRE ATT&CK来规划Red Teaming行动所需的TTPs；

  • 模拟未知威胁者：根据真实入侵的各个阶段收集到的具体目标信息实时地规划攻击路径从而模拟攻击者。

这三种方法其实应该算是Red Teaming行动在企业处于不同的威胁阶段时应该采用的不同方法，个人以为前两种应该作为甲方企业自身Red Team的主要工作方向，第三种可作为前两种的进阶补充或者乙方Red Teaming服务的工作重心。具体而言，第一种方法主要是模拟直接威胁者，通过威胁情报提前发现直接威胁者的TTPs并加以模拟来检测防守团队应对直接威胁的防御能力，这是Red Teaming行动的基本目标；第二种方法主要是模拟已知威胁者，通过模拟目前所有已知的攻击组织的TTPs来全面而系统地识别防守团队的防御弱点并帮助其提高检测所有已知威胁的覆盖率，这是Red Teaming行动的主要目标；第三种方法主要是模拟未知威胁者，通过模拟真实黑客的潜在入侵行为来检测当前企业面对未知威胁的防御能力，这是Red Teaming的进阶目标。

本文将重点介绍一下第二种方法即利用MITRE ATT&CK来规划Red Teaming行动从而全面而系统地模拟已知威胁者，换句话说就是以ATT&CK里所列的TTPs以“连点成线”的方式来规划所有可行的攻击路径。

实践

我们都知道官方的ATT&CK框架只是笼统地归纳总结了所有目前已知的攻击者的Tactics（战术阶段）和每个Tactics对应的Techniques（技术点），但却并没有深入地介绍每个Technique的具体技术细节，这实际上就为Red Teaming行动的模拟带来了很大的不便，也就意味着Red Team自己需要分析和整理一个包含每个技术点详细介绍的ATT&CK框架，笔者根据自身的实践经验已经做了类似的落地工作如下：

有了这样的基本框架，作为Red Teaming行动的实施者就可以按照以下的步骤来规划和实施具体的Red Teaming行动了。

确定目标

确定Red Teaming行动的目标通常是评估行动结果与效果的最有价值的衡量标准，因此行动前制定明确可度量的目标是非常重要的。比如，我们可以制定以下的行动目标：

  • 成功地在目标系统或者网络里执行所有已经选取的TTPs；

  • 识别所有选取TTPs被防守团队检测和中断所花费的时间。

制定计划

一旦确定了行动目标，我们就可以依据ATT&CK框架来制定具体的行动计划了。首先，我们可以按照不同的Tactics把整体的行动分为以下几个阶段。

事前准备(Pre-Attack)

  • T1266 – Acquire OSINT data sets and information. 从开源情报数据中收集目标企业员工的邮箱信息。

初始访问（Initial-Access）

  • T1192 – Spearphishing Link. 利用第三方可信的云存储服务来存放恶意的Word文档作为钓鱼链接。

执行（Execution）

  • T1155 – AppleScript. 利用AppleScript在Mac上运行Python脚本。

  • T1059 – Command-Line Interface. 使用cmd.exe执行系统命令和恶意代码。

  • T1085 – Rundll32. 利用Rundll32执行恶意DLL文件。

  • T1118 – InstallUtil. 利用InstallUtil执行恶意代码。

  • T1086 – PowerShell. 利用PowerShell在Windows上下载和执行恶意代码。

持久化与特权提升（Persistence & Privilege Escalation）

  • T1197 – BITS Jobs. 使用BITSAdmin下载恶意文件。

  • T1053 – Scheduled Task. 利用schtasks建立计划任务实现持久化和特权提升。

防御绕过（Defensive Evasion）

  • T1221 – Template Injection. 使用Word远程模版注入的方式执行恶意宏绕过邮件网关的沙箱检测。

  • T1088 – Bypass User Account Control. 利用Windows计划任务中的环境变量绕过UAC。

凭据访问（Credential Access）

  • T1003 – Credential Dumping. 利用Procdump拉取lsass.exe进程的内存并从中获取明文的用户凭据。

命令与控制（Command and Control）

  • T1104 – Multi-Stage Channels. 使用各种后门工具，Metasploit反向Shell，甚至是RAT工具来作为多层C2通道。

  • T1219 – Remote Access Tools. 利用开源RAT打造自己的远程控制平台。

数据渗出（Exfiltration）

  • T1041 – ExfiltraOon Over Command and Control Channel. 通过C2通道渗出目标数据。

然后，我们就可以根据上述选择的TTPs设计具体的模拟攻击路径，如下图：

准备TTPs

根据上面制定的行动计划，我们接下来需要分析所有已选取TTPs的具体技术实现，准备payload以及相应的测试，这时我们就需要依赖在本节一开始提到的包含每个Techniques具体技术细节的ATT&CK攻击框架，以下以部分在上述已制定的行动计划中选取的TTPs的准备为例。

T1192 – Spearphishing Link. 利用第三方可信的云存储服务来存放恶意的Word文档作为钓鱼链接。

T1155 – AppleScript. 利用AppleScript在Mac上运行Python脚本。

T1085 – Rundll32. 利用Rundll32执行恶意DLL文件。

T1197 – BITS Jobs. 使用BITSAdmin下载恶意文件。

T1221 – Template Injection. 使用Word远程模版注入的方式执行恶意宏。

T1003 – Credential Dumping. 利用Procdump拉取lsass.exe进程的内存并从中获取明文的用户凭据。

T1219 – Remote Access Tools. 利用开源RAT打造自己的远程控制平台。

T1041 – ExfiltraOon Over Command and Control Channel. 通过C2通道渗出目标数据。

依据以上TTPs的技术细节，我们就可以快速地制作Red Teaming行动各个阶段所需的payload（如钓鱼样本，反弹shell样本，持久化与特权提升样本等）和工具（如C2平台，RAT远控工具等）。

实施攻击

计划好Red Teaming行动的具体时间表（例如尽量避开公司业务高峰期和敏感期，尽可能地减少对实际业务的潜在影响），按照规划好的攻击路径和已经准备好的TTPs对目标企业网络实施攻击。

完成报告

在完成攻击后，完整且详细地记录以上各个步骤的详细信息和攻击行为时间线，对照行动开始前确定的目标完成结果分析，并最终形成报告，提交至防守团队进行复盘和改进。

总结

洋洋洒洒写了这么多，总结起来其实就是一句话：Red Teaming的攻击形式多种多样、纷繁复杂，短期内也不太可能找到一种万能的框架或者方法来模拟所有可能的攻击路径，在此情况下，利用ATT&CK来指导和落地Red Teaming行动仍不失为帮助防守团队识别当前企业面临的TOP安全威胁的有效方法之一。

参考

安全建设

企业安全建设的体系思考与落地实践

前言

企业安全建设是一个老生常谈的问题，由于每个人的工作经验和心得体会的不同，因此看法和实践通常也不一样。此文仅是笔者最近一段时间关于企业安全建设的体系思考和落地实践的一些个人看法，提供一种思考和分析问题的方式，仅代表笔者当前阶段的认知以及个人的阶段性总结。切记，“尽信书则不如无书”！

什么是体系思考

所谓体系思考，就是通过自身的知识和经验的积累，结合企业的现状，对存在的安全问题进行分类和整理，并总结出一套适合的安全建设体系的思考方式。有了这样的思考能力，就可以帮助我们形成合适的安全方法论来快速解决安全建设过程中的种种问题，做到目标明确，思路清晰，步步为营。

一谈到体系思考，相信很多人的第一感觉肯定是觉得很虚，认为只有不懂技术的人喜欢拿这种东西来装x，并喜欢以此来掩盖自己技术上的不足。实际上，笔者在很长一段时间内也是存在这种观点，然而随着工作经验的慢慢积累，越发觉得这种观点的片面性和不可靠性。不可否认，安全行业或者说所有行业里都或多或少存在以此为噱头的“砖家”，但是这并不能否定掉体系思考的价值和重要性。从某种程度上来说，体系思考可能比具体的技术实践更加重要。举个例子，笔者经常看到一些一个人安全部的文章，写的很详实，建立各种系统，解决各种当前存在的安全问题，当读第一遍的时候你可能会觉得写的不错，可是当你仔细读完之后，你会慢慢发现似乎缺少了一个贯穿始末的中心线，而这个中心线就是“体系思考”。设想，如果我们在做企业安全建设时进行了很好的体系化思考，明确知道当前所处的阶段，当前阶段的目标与困境，实现目标和解决困境的思路，落地实践的计划，那么我们就可以更加清楚地明白我们为什么建设这些系统且哪些安全问题需要被优先解决而不至于陷入“跟风”或者“人云亦云”的窘境，这时我们解决的就不在是一个个的表面问题而是一类的根本问题。

如何进行体系思考

明确体系思考的重要性是进行企业安全体系化建设的重要前提。根据笔者的个人经验，培养体系思考能力一般需要如下过程：

  • 积累：知识的积累是进行体系思考的前提和基础，需要了解和见识足够多的行业最佳实践，各种落地实践中面临的难点，解决难点的思路和方法。
  • 分类：有了一定的知识积累，需要对这些知识进行很好的整理，分类和总结。
  • 思考：当零散的知识点被整理和分类后，需要通过5W1H+Not的方式对这些知识分类进行思考，例如：什么样的角色（who）在什么样的企业（where）在什么样的时间节点（when）出于什么样的的目的（why）以什么样的方式（how）做什么样的事情（what），以及不这么做又会如何（Not）。
  • 实践：通过思考一般可以在大脑中形成初步的体系，但仍旧是“纸上谈兵”，这时就需要透过实践来检测思考的结果，并及时修正一些由于当前思考的局限性造成的误解或者盲点，作为下一轮的知识积累，并如此往复。

如何从体系思考到落地实践

前面写了这么多“废话”，相信能够坚持看到这里的某些同学肯定要喷我了，“你扯了这么多大家都懂的道理，你到底有哪些体系思考的结果呢？Talk is cheap, show me the code”。本节笔者将尝试从具体的企业安全建设来阐述一下我的一些个人看法。

第一步，企业安全建设相关知识的积累，我个人的做法是：

一，学习国内外知名企业（如：国外的FAANG，国内的BAT等）的安全建设的思路和做法，最快捷的方式当然是入职这样的企业，或者也可以通过这些公司公开的blog，paper或者其他安全相关的资料来学习，如：

二，学习公开的网络安全标准和最佳实践，如：

第二步，企业安全建设的分类，这里我分享两种不同的分类方法：

一，基于企业资产保护的安全建设分类。该分类的核心思想是安全建设围绕着资产的保护，比如，我们一般可以把一个企业的资产大致分为以下几类：

  • 基础设施资产：包括网络资产，设备资产，物理资产等；
  • 业务资产：包括应用资产，数据资产等。

二，基于企业数据生命周期的安全建设分类。例如：阿里推出的DSMM (数据安全能力成熟度模型)就是一个比较典型的以数据生命周期安全为核心思想的分类方法：

  • 数据安全过程纬度：包括数据生命周期安全（数据的采集，传输，存储，处理，交换，销毁）和通用安全。
  • 能力成熟度等级纬度：基于统一的分级标准，细化组织机构在各数据安全过程域的五个级别的能力成熟度分级要求。
  • 安全能力纬度：明确组织机构在各数据安全领域所需要具备的能力维度，明确为组织建设、制度流程、技术工具和人员能力四个关键能力的维度。

第三步，企业安全建设的体系思考。根据第二步中提到的两种不同的分类，我们可以分别从不同角度思考如何进行体系建设。
一，针对基于企业资产保护的安全建设分类，我们首先明确我们的核心思想是资产保护，那么所有的安全建设的思路就需要围绕着这个核心来进行。因此，至少需要组建如下的团队来做支撑：

  • 对于基础设施资产，则需要基础架构安全团队来解决企业基础网络安全架构的安全风险和威胁，安全运营中心（SOC）团队来保证安全的持续运营、改进和交付。
  • 对于业务资产，则需要应用安全团队来保证业务程序、软件、系统和服务的安全开发以及业务数据在整个生命周期中的保护，安全合规团队来保证业务数据使用的合法与合规，风控团队来确保业务的连续性和风险的可控性等。

按照上述的思考方式，我们可以根据资产的细化对上述的团队进行更加细致的划分，并最终形成一个完整的安全建设体系。
二，针对企业数据生命周期的安全建设分类，这里的核心思想是数据在整个生命周期中的安全保护，那么当我们在思考安全建设体系时考虑的就应该是怎么通过具体的措施来逐步提升数据在每个阶段的保护措施。比如DSMM就可以按照人类常见的思考和解决问题的思路来理解，即：

  • 过程分割：将数据保护按照生命周期分割成若干个阶段，如：采集，传输，存储，处理，交换，销毁；
  • 列出关键点：针对每个阶段列出所有的关键点PA（过程域）；
  • 评估当前水平：对于每个关键点PA评估当前所处的成熟度的等级水平；
  • 细化操作要求：结合当前所处的成熟度等级的对每个关键点PA细化具体的操作要求BP（基本实践）；
  • 执行落地操作：根据具体的操作要求BP来进行安全建设和改进。

根据上面的思考过程，我们也可以初步形成一个较为完整的安全建设体系。

第四步，企业安全建设体系的落地实践。我们还是以上面两种基于不同角度思考得出的安全体系来做例子。
一，针对以资产保护为核心的安全体系，落地实践的重点强调的是对于各个细化资产的安全保护。比如，

  • 网络设备的保护：防火墙 (Juniper FW)，IPS/IDS (Suricata/Snort)，DPI (Bro)，堡垒机，Web代理网关(IronPort)，邮件网关(FireEye/IronPort)，DNS RPZ，VPN，WiFi等；
  • 网络架构的保护：NAC，SDN，ZeroTrust (类似于Google的BeyondCorp)，VPC等；
  • 服务器／办公电脑的保护：反病毒，EDR，HIDS/HIPS等；
  • 移动终端的保护：MDM (VMware AirWatch)等；
  • 物理门禁的保护：异常警报，访问日志，监控摄像头等；
  • 业务系统和服务的保护：SDLC (包括安全开发规范以及相关的自动化工具、流程、平台的建设)，VRP (漏洞赏金计划)等；
  • 业务数据的保护：数据分类标准，数据处理标准 (传输和存储)，数据共享要求，合规管理要求，业务风控体系，通用安全系统和组件(KMS, 统一认证和授权平台，AAA)等；

当具备了以上这些用于保护各种资产的安全系统或者规范后，我们就可以做更多的系统分析和互相联动，具体可以参见笔者之前写的几篇文章《谈一谈如何建设体系化的安全运营中心(SOC)》，《甲方安全建设的一些思路和思考》，《Red Team从0到1的实践与思考》。
二，针对以数据生命周期安全为核心的安全体系的落地实践，DSMM已经表述的很详细了，具体参见http://www.hackliu.com/wp-content/uploads/file/20180326/1522063004775728.pdf，这里就不在赘述了。

此外，有了这些具体的实践措施，如何做到顺利的落地呢？笔者提供以下两种不同的思路供大家参考和探讨：
一，从上而下的思路，此方法适用于大型或者安全成熟度较高的企业。通常情况下，这类企业由于安全建设已经相对完善，安全的目标也相对明确，针对此种情况的落地通常可以从上层设置目标开始，逐步制定短中长期计划，建立相应的支撑项目，最后落地实践。
二，从下而上的思路，此方法适用于中小型或者安全成熟度较低的企业。这类企业由于安全建设的不完善，通常比较难在短时间内找到明确的目标来指导实践的落地。这时，反向操作的效果可能会更好点，比如：先评估当前企业面临的真实威胁、风险和外部要求（如合规和政策需求，第三方合作需求），然后评估优先级，接着建立不同项目来解决问题，随后根据项目的成果来指定短中长期计划，最后利用这些计划和已知的数据来设定目标（即所谓的数据驱动安全），随着安全体系建设的逐步成熟便可以采用从上而下的思路来继续完善和持续改进。

后记

引用一段《中国超越》这本书的作者张维为教授曾经在其书中提到的一段话：

邓小平说过，一个听过枪声的士兵和没有听过枪声的士兵就是不一样，实地考察过一个地方和没有考察过也是不一样的。

笔者认为这句话同样适用于这篇文章的主题，如果没有亲身参与过体系化的安全建设或进行过体系化的安全思考，那么本文所提到的内容可能并不能使您感同身受或者有所收益，但期望这篇拙劣的文章可以给您带来一丝思考和启发。

最后，在此深深地感谢平时在工作学习中给予我帮助和指导的行业前辈们以及来自于“基于量子透明计算的可信自主可控区块链式拟态安全态势感知的威胁情报联盟微信交流群”的群友们，让笔者深知学习、思考、分享和交流的重要性。

参考

安全建设

Red Team从0到1的实践与思考

0x00 前言

近年来Red Team越来越收到国内外企业的关注，恰逢笔者正在一家大型互联网公司从事Red Team相关的工作和实践，故以此文来简单阐述一下笔者对于Red Team从0到1的一些实践和思考。正所谓“一千个人眼中有一千个哈姆雷特”，此文中仅探讨笔者亲历的Red Team建设工作以及体系思考，观点谨代表个人，读者需酌情参考。

0x01 Red Team是什么

Red Team的概念最早来源于20世纪60年代的美国军方，原文定义如下：

An independent group that challenges an organization to improve its effectiveness by assuming an adversarial role.

翻译过来的大致意思是：一个通过承担对抗性角色来挑战组织以提高其有效性的独立的团体叫做Red Team。

后来，由于信息安全行业与军方的一些相似性，这个概念被引入到了安全行业，现在国际上一般以如下比较通用的定义来描述信息安全行业中的Red Team：

基于情报和目标导向来模拟攻击者对企业实施入侵的专门的安全团队。

由于Red Team和传统的渗透测试在一些攻击手法上有一些类似，二者很容易引起大家的混淆，很多人甚至干脆把他们混为一谈。我们可以从以下几个方面谈谈二者之间的主要区别：

  • 方法：前者主要来源于威胁情报，后者则是利用黑客的思维来发起攻击；
  • 目标：前者侧重于检测防御能力的弱点以及评估潜在的业务影响（下一节会详细介绍），后者则是在有限的时间内尽可能地发现更多的漏洞；
  • 计划：前者比较灵活且无固定时间限制，后者则需要指定目标范围和测试时间；
  • 过程：前者注重测试的隐蔽性，尽可能的绕过现有的防御系统，后者一般会提前告知防御团队且设置白名单例外，无需隐藏测试行为。

0x02 Red Team的目标

既然已经知道了Red Team的定义，就需要进一步了解一下Red Team的目标，要知道Red Team并不是为了攻击而攻击。我们经常会看到一种比较常见的观点是认为Red Team的目标是站在攻击者的角度来模拟真实入侵者攻击企业从而识别企业的防御弱点。笔者认为这个观点并不完整，也因太过笼统不足以清晰地表述Red Team的目标。其实可以结合前一节中的定义，来细化Red Team目标，具体包含下面几个部分：

  • 学习和利用已知真实攻击者的TTPs来用于攻击：因为Red Team是以情报和目标为导向的，因此我们需要通过威胁情报来了解已知真实攻击者的攻击目标和意图，以及通过ATT&CK和APT组织的分析报告来学习真实攻击者攻击不同行业的TTPs，这样有利于我们有针对性地模拟真实攻击者来攻击目标企业；
  • 评估现有防御能力的有效性以及识别防御体系的弱点并提出具体的应对方案：这是Red Team最为人所知的目标之一，让Blue Team通过已发现的不足来强化防御能力和改进流程，并最终提高真实攻击者的攻击成本；
  • 利用真实有效的模拟攻击来评估因为安全问题所造成的潜在的业务影响：这一点通常很容易被忽略，通过Red Team我们可以为企业管理者提供有效的数据来量化和衡量安全投入的ROI。

0x03 谁需要Red Team

Red Team听起来似乎价值很大，那么是不是所有企业都需要Red Team呢？答案是否定的。事实上，Red Team是建构在有相对健全或者成熟的防御体系之上的，这一点从上一节谈到的目标中有很好地体现。一般来说，一个企业只有拥有了基本的防御和检测的能力，并需要持续检验和改进这种能力时，Red Team才是一个非常不错的选择。如果一个企业连基本的入侵检测能力都没有健全，这种时候搞Red Team就好比空中楼阁，也没有实际的价值和好处。

0x04 Red Team如何工作

本节我将尝试从基本构成，工作流程，协作配合几个角度来谈谈Red Team如何在企业落地实现。

基本构成

在开始组建Red Team时，以下几个部分是不可或缺的基本构成，有了这些基础我们才能开展后续的Red Team工作。

知识储备

为了更好地模拟已知真实攻击者来实施攻击，一般情况下，我们可以通过威胁情报报告，ATT&CK， APT组织分析报告等来积累和学习这些真实攻击者的TTPs。其中一种流行的方法是，以ATT&CK Matrix和APT组织为参考，对具体的攻击技术细节进行分析和总结。

基础架构

工欲善其事，必先利其器。一次成功的Red Team活动是离不开强有力的基础架构的支持的，我们一般按照Red Team的攻击流程至少需要以下几类系统或工具：

  • 信息收集工具：如OSINT（Maltego，Shodan，Censys，Google Dorks，Github，SNS等），企业邮箱和域名采集工具（The Harvester等），漏洞扫描器等；
  • Payload生成工具：如Cobalt Strike，Metasploit，Empire，DotNetToJScript，SharpShooter，CACTUSTORCH，macro_pack等等；
  • C2架构：包括钓鱼与payload分发系统，基于各种协议（DNS，HTTP，ICMP）或者外部系统（Domain Fronting，Github，SNS等）的short-haul和long-haul C2，如：

安全建设

谈一谈如何建设体系化的安全运营中心(SOC)

0x00 前言

本文主要是谈谈笔者对于如何建设体系化的安全运营中心(SOC)的一点经验和思考，观点仅代表个人，仅供参考，不具普遍意义。

0x01 什么是SOC

SOC, 即Security Operations Center，我们一般称之为安全运营中心，主要是负责企业的入侵检测，应急响应，以及安全监控等，通常我们会笼统地概括成两个方面即Blue Team (Defensive Security)和Red Team (Offensive Security)，详见《甲方安全建设的一些思路和思考》，这里不再赘述了。

那么什么样的企业需要SOC呢？笔者认为凡是有安全团队的企业都需要这样的一个团队。唯一的区别在于，企业规模的大小和业务的复杂性决定了SOC的职责范围和其运作方式。举个例子，对于规模较大的互联网企业，它的SOC的职责包括但不限于以下几种:

  • Incident Response (应急响应)
  • Malware Analysis (病毒分析)
  • Digital Forensics (电子取证)
  • Threat Hunting (入侵检测)
  • Threat Intelligence (威胁情报)
  • Vulnerability Management (漏洞管理)
  • Penetration Testing (渗透测试)
  • Red Teaming

而规模较小的企业，则可以按照企业实际的规模和业务需要逐步包含以上的职责范围。

0x02 如何组建SOC

理论基础

在组建SOC之前，我们需要对一些基本安全理论有一定的了解。只有掌握了这些基础理论知识，我们在组建SOC的时候就会比较有针对性和方向性。

应急响应的ACERR处理模型

一般情况下，任何安全事件的应急响应都可以分为以下几个阶段：

  • Assessment（评估）：主要是初步梳理安全事件的类型，产生的原因和评估潜在影响范围；
  • Containment（控制）：这个阶段主要是快速找到止损/减轻方案（或者是临时应对措施）将事件影响尽可能控制在最小范围内；
  • Eradication（消除）：这个阶段是要找到安全事件产生的根本原因并提出和实施根治方案；
  • Recovery（恢复）：主要是确保所有受影响的系统或者服务完全恢复到安全状态；
  • Review（总结和审查）：这是每个应急响应的最后阶段主要是总结和梳理安全事件处理和响应的整个时间线和应对方案，学习和审查安全事件产生的根本原因并生成知识库以便以后遇到同类安全事件可以快速地找到处理和应对的方法。

Cyber Kill Chain模型

Cyber Kill Chain模型将攻击者的攻击过程分解为如下七个步骤:

  • Reconnaissance（侦查）: 入侵者选择目标，对其进行研究，并尝试识别目标网络中的漏洞;
  • Weaponization（工具化）: 入侵者创建针对一个或多个漏洞定制的远程控制的恶意软件工具，例如病毒或蠕虫;
  • Delivery（投送）: 入侵者将恶意软件工具投递到目标（例如，通过电子邮件附件，网站或USB驱动器）;
  • Exploitation（攻击利用）: 恶意软件工具的利用触发器，它在目标网络上执行来利用漏洞;
  • Installation（安装植入）: 恶意软件工具安装入侵者可用的后门;
  • Command and Control（命令与控制）: 恶意软件使入侵者能够对目标网络进行持久访问和利用;
  • Actions on Objectives（目标行动）: 入侵者采取行动实现其最终目标，例如数据泄露，数据销毁或加密勒索。

通过以上的模型将攻击者的攻击过程分解，我们就可以找到对应的防御方法：

  • Detect（检测）：确定攻击者是否在嗅探或者扫描；
  • Deny（拒绝）：防止信息泄露和未授权访问；
  • Disrupt（中断）：阻止或更改攻击者的出站流量；
  • Degrade（降级）：反击命令与控制；
  • Deceive（欺骗）：干扰命令与控制；
  • Contain（控制）：网络分段隔离。

MITRE’s ATT&CK矩阵

MITRE’s ATT&CK矩阵，是一个用于分析网络入侵者的战术和技术的知识库，它可以用于了解和分析攻击者所有当前已知的攻击技术和行为，以便于规划安全性改进以及验证防御体系是否正常工作。通俗地说，这其实就类似于对攻击者进行画像，再利用这个入侵分析矩阵来全面了解我们的攻击者从而帮我们来设计和改进我们的防御体系。

系统工具

这部分可以参照以下资源，这里就不再赘述了：

0x03 SOC如何工作

当我们组建好了SOC，如何才能让其有效的工作呢？下面我将分别从组织架构，职责划分，有效协作几个方面来做简单地的讲解。

组织架构

SOC就像一台机器，而SOC的每个组成部分就是机器的一个个零部件。一个体系化的SOC运营就是把整体的安全运营拆分成一个个独立的子模块，通过各个子模块之间的相互配合和协作，最终有效处理一个复杂的安全事件。从组织架构上，一般会把SOC分解为Defensive Security团队和Offensive Security团队，如下：

职责划分

SOC组织架构是需要支持不同的工作职责的，我们把这些不同的子模块/团队按照职责的不同划分成以下几类：

Tier 1团队

主要负责直接应对和处理企业内外的各种安全事件，例如：Incident Response，提供7*24小时的应急响应服务。这类团队通常需要具备足够的技术知识面，良好的沟通和协调能力，出色的安全事件分析能力等。

Tier 2团队

主要为Tier 1团队提供技术上的深度支持，例如：Malware Analysis，Digital Forensics，Threat Hunting，Threat Intelligence，以及Vulnerability Management等。这类团队注重的是分析和调查安全事件和问题的根本原因，实施有效的应对措施和防御策略。

Tier 3团队

主要负责从攻击视角来检验当前已有的入侵检测和防御能力，例如：Penetration Testing和Red Teaming等。这类团队侧重于站在入侵者的角度来模拟实际的攻击者对企业资产和信息实施有计划和目的的渗透和入侵，以此来检验Tier 1和Tier 2团队的应对和处置能力，包括：

  • 能否检测到？
  • 多久能检测到？
  • 检测到什么程度？
  • 有无实时阻断能力？
  • 多久能阻断？
  • 等等…

有效协作

当我们已经具备了以上的组织架构和清晰的职责划分，接下来一个问题就是如何让各个团队之间进行有效的协作从而发挥最大的功效来应对各种安全威胁，我将尝试用下面几个典型的案例来简单加以阐述。

被动应急与响应

Incident Response团队收到一个员工上报的钓鱼邮件，进过初步分析发现该钓鱼邮件附带一个HTML文件引诱收件人点击一个外部链接来下载和打开一个Word文档文件，沙箱分析这个文档不包含任何宏来启动PowerShell或者VB脚本等常见利用方法。

首先，Incident Response团队对外部可疑域名执行DNS sinkhole操作。应急响应人员迅速查询邮箱安全网关日志发现多个内部员工收到了来自于该外部可疑发件人的邮件，并立即清除所有邮件服务上的该可疑邮件，同时更新邮件网关的检测和过滤规则。

随后，Malware Analysis团队去深度分析和调查该Word文档。经调查发现该可疑样本利用了一个已公开披露的Office软件的漏洞执行命令从Stage 2域名下载并安装后门来链接C2的IP，调查结果反馈给Incident Response团队。

然后，Incident Response团队根据已获得域名和C2信息分析网络，EDR，DNS，DHCP等日志找到所有执行该Word文档的终端电脑和用户。

Digital Forensics团队跟进对已感染终端进行实时或者线下取证分析获取到更多的IOC和TTP信息，调查结果同样反馈至Threat Hunting和Incident Response团队。

Incident Response团队梳理所有已知信息（包括：域名，IP，文件hash，命令行，注册表等等）添加至IOC检测平台，确保终端防病毒软件可以检测所有已知的后门样本，确保所有已知恶意域名和IP被block，隔离所有已感染主机，重置已感染用户的用户凭证等等。

Vulnerability Management团队扫描所有存在该office软件漏洞的主机并进行补丁推送。

Threat Hunting团队根据所有已知的TTP开发和添加检测规则或者模型用于主动检测。

主动检测与响应

Threat Hunting团队针对某类恶意软件的行为特征开发了一个检测规则或者模型，并触发了一例可疑的告警。

Incident Response团队的安全分析师跟进调查EDR日志发现某终端主机确实存在与该类恶意软件类似的行为特征，并联系Digital Forensics和Malware Analysis团队对感染主机进行实时取证分析和Malware分析，结果显示该恶意软件生成了可以bypass当前终端防病毒软件的后门，并利用了一些当前检测规则未知的方式来与C2通信。同时，分析发现该恶意软件的感染是由于员工安全意识不足插入了不可信的U盘等外部设备引起的。

之后，与被动应急与响应类似，Incident Response团队梳理所有已知信息（包括：域名，IP，文件hash，命令行，注册表等等）添加至IOC检测平台，确保终端防病毒软件可以检测所有已知的后门样本，确保所有已知恶意域名和IP被block，隔离所有已感染主机，重置已感染用户的用户凭证等等。并对引起该问题的员工所在的部门强制进行企业安全意识培训。

最后，Threat Hunting团队根据所有最新调查发现的TTP来更新或者优化当前的检测规则或者模型，以此来形成一个有效的主动检测与响应的安全闭环。

威胁情报分析与利用

Threat Intelligence团队通过情报共享组织掌握到了一条最新的情报，即有黑客在知名黑客论坛售卖能够收集某些特定企业的用户数据的工具，其进行初步地分析和梳理该情报后发现：

  • 情报源的可靠性较高，因为其发布于知名黑客论坛，且该黑客以往多次售卖过类似可利用的工具；
  • 所在公司确实是该工具宣称的特地目标企业之一；
  • 该工具的主要作用是收集目标企业的客户支付信息和账户登录凭证信息；
  • 该工具的分发手法主要是社工和web攻击。

Threat Intelligence团队根据情报共享组织提供的已知IOC和OSINT信息整理出了初步的TTP，并反馈给Incident Response团队和Threat Hunting团队。

随后，Incident Response团队跟进分析确定了下一步的调查方向，比如：

  • 监控最近一段时间的登录接口以及涉及用户支付流程的页面是否产生了异常流量；
  • 检查最近企业的钓鱼邮件的过滤和分析结果，如钓鱼邮件的上升趋势；
  • 关注终端的恶意代码检查和趋势分析来尝试找到更多的可能的攻击痕迹；
  • 利用一些已知的IOC与内部的日志监控系统做匹配和联动，例如：该黑客的id是已知的，可以尝试做更多的匹配分析来检查恶意代码中是否存在与这个id有关的关键词等。

一旦上述任何调查方向有了新线索，便可以联系Tier 2团队跟进分析和调查，确定更多IOC和TTP，并做相应的应对措施。

最后同上，Threat Hunting团队根据所有已知的TTP开发和添加检测规则或者模型用于主动检测。

Red Teaming实践

Red Teaming团队通过以下的TTP来模拟Threat actors入侵企业从而检验Tier 1和Tier 2团队能否进行有效检测和响应。

目标（Goals）

模拟某个国家级的APT组织来入侵企业从而获得企业的敏感数据

战术（Tactics）

  • 鱼叉式钓鱼
  • 物理访问
  • 社工
  • 远控软件的投递与安装
  • 确保后门软件不能被虚拟机，debugger或者沙箱分析
  • 后门使用加密配置文件，支持高度定制和可配置化，如

    • phishing基础架构
    • C2基础架构
    • 持久化机制
    • 加密密钥
  • 基于Domain Fronting的C2通信

技术（Techniques）

  • PowerShell
  • 脚本化与无文件化，如：MsBuild.exe，DotNetToJScript等
  • 软件打包bypass防病毒软件
  • 保证持久化

    • 计划任务
    • 注册表/启动目录
    • 修改快捷方式
    • WMI（Windows Management Instrumentation）事件订阅
  • Bypass UAC来实现本地提权
  • Pass the Hash／Pass the Ticket来实现横向移动
  • Tor proxy配置以及Domain Fronting绕过流量检测

流程（Procedures）

初始感染

利用鱼叉式钓鱼发送钓鱼邮件，将恶意程序放置在信誉度良好的外部站点上，编写精心设计和欺骗性很高的邮件内容来引诱目标用户点击该外部链接打开恶意文档，如word文档，hta文件等。

建立根基

一旦目标用户打开恶意文档，执行PowerShell脚本下载不具备危险性的XML文档并调用MsBuild.exe来执行XML文档中内嵌的恶意代码注入内存来绕过防病毒检测生成一个具备少量功能的downloader，如偷取用户凭证，收集浏览器历史，或者截图等。

权限提升

通过已安装的downloader下发特定的用户凭证盗取工具(如：WCE, Mimikatz, Procdump, Keylogger等)来盗取用户密码或密码hash，同时收集防病毒软件的信息并绕过防病毒来完成权限提升。

内部侦查

通过一些常见的系统命令或者下发定制脚本来探测内网信息，如枚举域信息，组策略对象中的各种用户和用户组配置信息。

横向移动

使用收集到的用户凭证，PtH (Pass the Hash), PTT (Pass the Ticket)利用RDP，PsExec, Mimikatz, RemCom等来完成内网的横向移动。

维持权限

利用计划任务，注册表/启动目录，修改快捷方式等方式来保证持久化。

完成目标

逐步渗透内网的核心机器，偷取企业的核心数据，并利用DNS隧道，Domain Fronting或者加密数据通过HTTPS等更加隐秘的方式外带出去，达成最终目标。

实践活动完成后，Red Teaming团队与Tier 1和Tier 2团队复盘整个模拟入侵过程的时间线，分析和总结没有被检测到的点以及整个入侵防御体系存在的问题，并提出改进方案，以便在下一次的实践中检验改进成果。

0x04 总结

笔者观点，SOC的体系化建设：系统工具是基础，体系结构是重点，有效协同是关键。

0x05 参考

安全建设

甲方安全建设的一些思路和思考

0x00 前言

本文主要是介绍一下笔者对于甲方安全能力建设的一些经验，心得和零散的思考。需要特别强调的是不同企业的实际情况不尽相同，本文仅供参考，不具普遍意义。

0x01 Red Teaming

近几年随着Red Team建设的话题越来越流行，不管是甲方或者乙方都在极力的发展自己的Red Teaming能力，尤其是各个乙方都推出了自己的Red Team的服务，如：FireEye(https://www.fireeye.com/content/dam/fireeye-www/services/pdfs/pf/ms/ds-red-team-for-security-operations.pdf)，但是最终目的都是为甲方输出检验企业的Detection和Response的能力，找到防御弱点进而优化防御系统和流程。

我们不禁要思考一下，到底什么样的企业才真的需要Red Team？当然，输出安全能力和服务的乙方不在讨论范围内，因为其最终是为了服务和支持甲方。根据我的观察和发现，目前大部分人很容易把Red Team和Penetration Testing弄混或者干脆混为一谈。其实二者有共同点但也有本质上的不同，简单做个比喻就是忍者(隐秘，快速，准确，一击即中)和海盗（强壮，贪婪，可以刚正面，一波高地）的区别，各有侧重和优劣，但侧重点不同，比如，Red Team类似忍者，侧重于精心准备（如：社会工程学等）收集信息进而绕过现有的防御体系（类似于APT）来检验防御和检测能力；而Penetration Testing则如同海盗，侧重于尽可能多地发现应用，系统，网络，设备等的漏洞，并利用其发现更深层或者复杂的漏洞从而来评估风险。所以，答案显而易见，一个企业只有拥有了基本的防御和检测的能力，并需要持续检测和改善这种能力时，Red Team就是很好地选择了。

那么，什么样的Red Team才算合格和有效呢？如前面所说，Red Team如同忍者去做暗杀，既然暗杀那么就需要一个详细的计划，如：目标是什么（暗杀对方头目），手段是什么（前期侦查对方大本营，守卫布局，对方头目的日常习惯和出现的场所，会不会功夫等），如何去执行（选择某个夜黑风高的晚上，众人都准备或者已经睡觉的时候，摸进对方大本营，提前隐藏在对方头目习惯出现的场所，等待其出现，再一刀毙命）。对应到Red Team就是，

1）设置好这次行动目的是模拟偷取公司的客户资料；

2）提前做好侦查看看公司都可能有哪些人会碰到这类数据，有哪些防御检测方式（如：反病毒，入侵检测，流量分析）；

3）针对可能接触数据的人员做定向钓鱼攻击或者面对面的社工，安装专门制作的绕杀软的工具，利用常见的社交或者云存储网站来做C2，等待时机控制机器，获取必要的用户凭证，盗取客户资料，销毁痕迹，最终走人。

因此，一个合格的Red Team，需要具备模拟攻击者入侵的各种能力，手段以及假想的目的。想要具备这种能力的一个最简单有效的方法，就是从现有的真实世界里发生的APT攻击活动中抽取TTP来模拟真实的threat actors，分类并总结他们曾今采用的手段，方法，技术和工具，然后加以优化和改进，最终结合每个Red Team活动的假想目的来模拟不同APT组织对于公司的入侵，以此来检测已有的防御和响应体系是否有效。

0x02 Blue Teaming

我们在说Blue Team时，通常是指在一个企业里负责入侵检测和应急响应的团队的统称，一般情况下（尤其是规模较大的企业）会至少细分为以下几个团队：

  • Threat Hunting（入侵检测）：主要负责根据已知威胁的TTP（如APT活动）和根据常见入侵活动的行为特征（如批量端口扫描，同一系统账户的短时多次尝试登录，office软件进程的可疑子进程的派生等等）来开发入侵检测规则，或者利用机器学习，深度学习等更高级的数据挖掘技术来研究和分析威胁特征；
  • Incident Response（应急响应）：主要负责处理和调查企业的安全事件（如：外部应用系统被入侵，内网主机被入侵，以及由Threat Hunting的规则触发的各类入侵报警等）以及从真实的安全事件中来分析和提取自产的IOC以及最新的威胁特征；
  • Vulnerability Management（漏洞管理）：主要负责对企业所有资产（包括应用和原代码）的持续漏洞扫描，追踪，修复以及管理；
  • Threat Intelligence（威胁情报）：主要负责追踪和分析外部已知APT活动，地下黑市和深网或暗网里的各种威胁情报信息，并加以分类总结成TTP以及IOC提供给其他团队加以利用和深层分析（如前面提到的Threat Hunting，以及Red Team）。

而且这些子团队都不是独立工作的，其之间都是相互配合和支持的。我们可以举个常见的例子来加以解释一下，比如threat hunting可能会通过已知的规则发现了一个可能的入侵行为；接着incident response迅速跟进进行流量、日志或者取证的分析发现了之前未被识别的威胁特征；然后threat hunting基于该特征开发最新的检测规则，threat intelligence以此进行情报梳理和比对并最终发现这是某个最近比较活跃的APT组织的活动，随后搜集相关TTP反馈给threat hunting；最后，vulnerability management团队扫描企业所有可能存在弱点和受影响资产，追踪和修复。

综上可见，Blue Team不是gank选手，而是讲究的团队合作和相互配合的团战协作，合理的利用和集合各个子团队的优势便可以大大提高入侵检测的准确性和应急响应的快速性。

0x03 应急响应

在开始之前，先谈谈我个人理解的应急响应是什么？顾名思义就是对企业发生的安全事件作出快速应对和及时响应从而减少由于安全事件造成的影响。

一般情况下，任何安全事件的应急响应都可以分为以下几个阶段：

1）Assessment（评估）：主要是初步梳理安全事件产生的原因和评估潜在影响范围；

2）Containment（控制）：这个阶段主要是快速找到止损/减轻方案（或者是临时应对措施）将事件影响尽可能控制在最小范围内；

3）Eradication（消除）：这个阶段是要找到安全事件产生的根本原因并提出和实施根治方案；

4）Recovery（恢复）：主要是确保所有受影响的系统或者服务完全恢复到安全状态；

5）Review（总结和审查）：这是每个应急响应的最后阶段主要是总结和梳理安全事件处理和响应的整个时间线和应对方案，学习和审查安全事件产生的根本原因并生成知识库以便以后遇到同类安全事件可以快速地找到处理和应对的方法。

为了便于大家更好地理解怎么运用以上这些步骤来帮助我们做好应急响应，以下我以一个企业经常会碰到的钓鱼邮件为案例。比如，我们的企业员工上报了一封钓鱼邮件，那么作为应急响应团队应该怎么做？我们都知道钓鱼邮件是入侵者（APT组织）攻击大型企业的最直接有效的方法。当我们的应急响应人员遇到这样的攻击试图时，

第一步，我们要初步分析钓鱼邮件的攻击方法，通常有以下两种。分析了攻击方法，我们就需要评估影响，比如，哪些人收到了该邮件，哪些人可能访问了恶意链接，哪些人下载了恶意文件，哪些人执行了恶意文件，哪些数据可能受到影响等等；

  • Credential Harvesting：设置一个伪造的邮箱或者系统登录界面（如发送一个诱饵链接或者在邮件里嵌入一个html页面）来盗取有效的用户名和密码；
  • Malware：一般包括两种方式，一是通过附件直接发送恶意文件，二是通过发送链接来诱骗用户点击下载恶意文件。

第二步，实施控制措施或者减轻方案，如针对通过链接来偷取用户名和密码或者下载第一阶段的恶意文件的域名我们可以实施DNS sinkhole（详情可以参照：https://en.m.wikipedia.org/wiki/DNS_sinkhole），对于利用附件直接发送恶意文件的情况我们可以通过静态或者动态沙箱（例如cuckoo，virustotal等）来分析恶意文件的行为并抽取IOC（可能是后续阶段C2的域名或者IP，亦或者是执行的子命令）实施DNS sinkhole，防火墙IP黑名单，或者终端防安全防护软件添加行为识别特征或者文件hash黑名单等等措施；

第三步，当恶意行为被有效控制后，我们便需要实施清除活动，如：清除所有收到的恶意邮件，对访问过恶意链接并且可能潜在泄露过用户名和密码的用户进行账号重置，对于下载执行过恶意文件或者访问过后续阶段的域名或者IP的用户电脑进行重装等等；

第四步，这个阶段我们需要确保我们在第三步中的所有清除活动按照预期完成，并且所有用户和系统恢复正常使用；

第五步，当一切恢复正常，我们需要对这次的钓鱼邮件事件做复盘分析，如：为什么我们的邮件安全网关没有检测到和拦截这个钓鱼邮件？为什么我们的员工会点击这些钓鱼邮件？我们的防御和检测的漏洞在哪？下次再发生类似事件我们应该怎么办？等这些问题都找到对应的答案了我们则需要录入应急响应知识库以备后用。

综上，一个有效的应急响应是需要一个相对完整的流程来保证，如此一来便可以保证应急时不慌乱有条理且快速有效。

0x04 内网入侵检测与防御

本章节将依据我个人的一些工作经验和思考分别从平台搭建，工具配置，入侵调查与分析三个方面来聊聊企业的内网入侵检测和防御的建设思路。

一、平台篇

通常来说，一个企业要想做好内网检测和防御，首先要解决的问题就是感知能力，这就好比是人的五官要可以感知到周遭环境的变化，那么反映到安全平台上我们就需要一个统一的日志收集和分析平台。那么需要收集哪些日志呢？是所有的都收集吗？还是有选择性地收集？又如何来确定优先级呢？其实日志的收集切忌盲目全收，否则就会浪费了大量的人力物力财力到头来搜集了一堆日志却不知道如何使用。最好是结合应用场景来制定优先级，循序渐进。举个例子，比如当我们的一个应用场景是检测办公网中的入侵行为，我们需要解决的核心问题其实就是谁在什么时间什么机器上运行了什么进程做了什么操作。分解一下这个问题，首先我们需要有日志能帮我们定位每个内网用户，如：DHCP，DNS，Kerberos Tickets（AD认证），Windows Event Logs，Antivirus等；接着我们想要知道什么时间什么机器上运行了什么，如：主机进程树和网络连接日志（即：Event Tracing for Windows）等；最后我们需要知道做了什么操作（网络行为等），如：网络设备出口流量，Web网关日志（HTTP流量），IDS日志，WiFi日志，邮件网关日志等等。这样，我们就能有针对性地收集我们当下最需要的日志并可以利用这种方法来逐步扩大日志收集的种类。

有了统一的日志收集平台，接下来我们便需要一个持续的威胁检测平台其主要作用就是编写各种检测规则和机器学习模型来对所有收集到的日志进行匹配检查以保证之前的已知威胁不会被忽略。

接着，我们需要一个IOC检测平台，其主要作用是用来对外部情报信息或者内部自产的情报信息进行实时匹配和报警以确保当前所有的已知威胁能被检测出来。

最后，我们还需要一个内部威胁追踪和记录平台，其主要作用是用于流程化和规范化地记录和总结所有以往发生的入侵事件的调查过程和分析结果以便于日后查询和关联分析。

总之，安全平台建设是企业内网入侵检测和防御的基础，只有搭建了这些基础平台，才能谈后续的工具配置和入侵分析与调查。

二、工具篇

在上一篇中我们聊到安全平台建设是企业内网入侵检测和防御的基础，在这个基础之上今天我们来聊聊工具配置。简而言之，就是有了感知能力，需要哪些工具来帮助我们分析和调查入侵，所谓工欲善其事必先利其器。

一般来说，最常见的入侵内网的手法就是钓鱼邮件和社工，而其中以钓鱼邮件最为典型，因此做好钓鱼邮件的防范是最为简单有效的防御内网入侵的方法。我之前曾提到过钓鱼邮件的常见手法，

  • 发送链接模拟邮箱或者内部系统登陆界面收集企业员工的账号密码；
  • 发送链接诱导员工点击下载恶意的office文档；
  • 直接发送恶意的office文档或者PE文件或者恶意程序的压缩包作为附件并诱导员工打开。

针对以上几种手法，我们至少准备以下几类工具来辅助分析。
第一类，域名与IP检测工具：

  • https://centralops.net/co/DomainDossier.aspx?dom_whois=1&net_whois=1&dom_dns=1
  • https://www.threatcrowd.org/
  • https://www.threatminer.org/
  • https://www.virustotal.com/en/
  • https://www.talosintelligence.com/
  • https://login.opendns.com/
  • https://www.alexa.com/siteinfo
  • https://x.threatbook.cn/en
  • https://checkphish.ai/domain/avfisher.win

第二类，URL检测工具：

  • https://urlscan.io/
  • https://sitecheck.sucuri.net/results/pool.cortins.tk
  • https://quttera.com/
  • https://www.virustotal.com/en/
  • https://checkphish.ai/

第三类，TOR节点检测工具：

  • https://www.dan.me.uk/torcheck
  • https://exonerator.torproject.org/
  • https://ipduh.com/ip/tor-exit/
  • https://torstatus.blutmagie.de/

第四类，在线恶意程序或文档检测工具：

  • https://www.virustotal.com/en/
  • https://malwr.com/
  • http://camas.comodo.com/
  • https://x.threatbook.cn/en
  • https://www.reverse.it/
  • http://www.threatexpert.com/submit.aspx
  • https://www.vicheck.ca/
  • https://virusshare.com/
  • https://malshare.com/
  • https://github.com/ytisf/theZoo

第五类，动态恶意程序或文档分析工具：

  • Cuckoo: https://github.com/cuckoosandbox/cuckoo
  • Regshot: https://sourceforge.net/projects/regshot/
  • Process Hacker: http://processhacker.sourceforge.net/
  • Process Monitor: https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
  • ProcDOT: https://www.cert.at/downloads/software/procdot_en.html
  • WinDump: https://www.winpcap.org/windump/
  • Graphviz: http://www.graphviz.org/Download..php
  • Capture-BAT: https://www.honeynet.org/node/315 (x86 environment only)
  • Fakenet: https://sourceforge.net/projects/fakenet/
  • Wireshark: https://www.wireshark.org/#download

第六类，邮件检测工具：

  • http://spf.myisp.ch/

第七类，Google搜索，这也是最简单暴力但却十分有效的工具之一。

在分析内网入侵时合理地使用以上这些工具往往会有事半功倍的效果。另外，作为一个入侵分析和响应工程师切忌在没有网络隔离的情况下在办公电脑上直接访问可疑链接或者分析恶意样本文件。

三、分析篇

在前两篇中，我们分别谈到了企业内网入侵检测和防御所需要的安全平台建设和工具配置，有了这些基础我们便来聊聊如何运用这些已有的平台和工具来分析真实的内网入侵事件。

为了更好的说明这个问题，我将仍以最常见的利用钓鱼邮件入侵企业员工电脑并进而入侵内网为例来说明如何分析这类的入侵事件。为了能够检测和分析这类入侵事件，我们需要有能力获得最原始的钓鱼邮件，这就需要我们从至少以下几个途径来获取：

  • 企业员工主动提交可疑的钓鱼邮件，这就需要员工具备一定的安全意识（安全意识培训的重要性），以及统一的可疑邮件提交平台（需要开发成本）
  • 邮件安全网关，如：Ironport，FireEye Email Security等
  • IOC检测平台，及时检测已知的恶意域名或者IP，可疑的发件人，恶意附件等

当我们拿到了原始的钓鱼邮件，首先需要确保将其转化成EML文本格式（可用工具https://github.com/mvz/msgconvert），接着，我们至少需要从以下几个方面来分析：

1）原始邮件头，包括：From, envelope-from, SPF, client-ip等;
1.1）可以通过dig命令，如：dig -t txt baidu.com，来检查邮件是否被spoof了;
1.2）对比From和envelope-from是否一致，也是一个判断是否为恶意邮件的有效方法.
2）原始邮件正文，包括：域名／IP，URL，附件等;
2.1）域名/IP和URL的分析可以使用工具篇里提到的相应工具来分析，判断是否存在multi-stage C&C;
2.2）附件的分析也可以使用工具篇里提到的在线／本地恶意程序分析沙箱或者自行逆向分析，进而了解恶意程序的执行逻辑以及对应的IOC(域名，URL，文件，注册表键值，执行的系统命令等);
2.3）利用日志分析平台，查询恶意域名的DNS或者HTTP(S)流量日志，结合主机EDR（Endpoint Detection and Response）终端日志将DNS请求关联到相应的主机进程，如：ETW for Windows，BCC/eBPF for Linux等;
2.4）查询触发恶意域名的DNS请求的主机进程的整个进程树，分析malware完整的执行链，例如：outlook.exe -> winword.exe -> cmd.exe -> powershell.exe;
2.5）查询所有触发了上述执行链的受感染主机，并重复2.4）的步骤直到没有新的执行链被发现为止.

在分析完了以上这些，我们就可以添加对应的防御和检测措施了，例如：

1）通过应急响应章节中提到的DNS Sinkhole来阻断所有恶意域名的DNS请求;
2）确保终端反病毒程序可以检测并清理每个阶段的恶意文件;
3）添加防火墙规则来阻止内网主机对恶意IP地址的访问;
4）隔离重装已经感染的主机进行;
5）重置受感染内网用户的登录凭证;
6）删除所有企业用户收到的来自同一恶意发送者的邮件;
7）将分析得出的IOC添加到IOC检测平台;
8）依据已发现的Malware执行链添加新的入侵检测规则.

至此，我已简单地介绍了一个相对完整的针对利用钓鱼邮件入侵企业员工电脑并进而入侵内网的入侵事件的分析和防御的方法与流程。

应用安全、磨利器

一个简单的分布式WEB扫描器的设计与实践

0x00 前言

作为一个安全从业人员，在平常的工作中总是需要对一些web系统做一些安全扫描和漏洞检测从而确保在系统上线前尽可能多的解决了已知的安全问题，更好地保护我们的系统免受外部的入侵和攻击。而传统的web安全检测和扫描大多基于web扫描器，而实际上其是利用爬虫对目标系统进行资源遍历并配合检测代码来进行，这样可以极大的减少人工检测的工作量，但是随之而来也会导致过多的误报和漏报，原因之一就是爬虫无法获取到一些隐藏很深的系统资源（比如：URL）进行检测。在这篇文章里，笔者主要想和大家分享一下从另一个角度来设计web扫描器从而来解决开头所提到的问题。

0x01 设计

在开始探讨设计之前，我们首先了解一下web漏洞检测和扫描的一般过程和原理。通常我们所说的web漏洞检测和扫描大致分为2种方式：

  • web扫描器：主要利用扫描器的爬虫获取目标系统的所有URL，再尝试模拟访问这些URL获取更多的URL，如此循环，直到所有已知的URL被获取到，或者利用已知字典对目标系统的URL进行暴力穷举从而获取有效的URL资源；之后对获取的URL去重整理，利用已知漏洞的检测代码对这些URL进行检测来判断目标系统是否存在漏洞
  • 人工检测：通过设置代理（如：burp）来截获所有目标系统的访问请求，然后依据经验对可能存在问题的请求修改参数或者添加检测代码并重放（如：burp中的repeat功能）从而判断目标系统是否存在漏洞

对比上面的2种方式，我们可以发现web扫描器可以极大的减少人工检测的工作量，但是却因为爬虫的局限性导致很多事实上存在的资源不能被发现容易造成就误报和漏报；而人工检测可以很好的保证发现漏洞的准确性和针对性，但是却严重依赖于检测人员的经验和时间，尤其是大型系统很难在有限的时间内完成检测，同样会造成漏报。那么，如果能有效地利用扫描器的处理速度以及人工的精准度的话，是不是就可以很好地解决前面的问题了呢？

下面让我们来深究一下两者的各自优势，前者自动化程度高不需要过多的人为干预，后者因为所有请求均来自于真实的访问准确度高。我们不禁思考一下，如果我们有办法可以获取到所有的真实请求（包括：请求头，cookie，url，请求参数等等）并配合扫描器的检测代码是不是更加有针对性且有效地对系统进行漏洞检测呢？

我们设想一下，如果有这样一个系统可以在用户与系统之前获取到所有的请求，并分发给扫描器进行检测，这样只要请求是来自于真实的应用场景或者系统的功能那么就可以最大程度地收集到所有真实有效的资源。故可以设计该系统包含如下的子模块：

  • 客户端：用户访问系统的载体，如：浏览器，手机APP
  • 代理：用于获取来自于客户端的所有请求，如：Burp，Load Balancer
  • 解析器：负责将代理获取的请求数据按照规定格式解析并插入至请求数据库中
  • 请求数据库：用于存放代理获取的所有请求数据以及解析器和扫描器的配置信息
  • 扫描器：具有漏洞检测功能的扫描器，如：自行编写的定制扫描器（hackUtils），SQLMAP，Burp Scanner，WVS，OWASP ZAP等
  • 应用系统：目标应用系统，如： Web系统，APP

基本架构如下：

从上图的设计中，我们可以利用代理将所有访问目标系统的请求获取并存储在一个统一的数据库中，然后将这些真实产生的请求分发给不同的扫描器（比如：常见的OWASP Top10的漏洞，已披露的常见框架或者中间件漏洞等）进行检测。上述设计是高度解耦合地并且每个子模块都是只负责自己的功能相互之间并不干扰，且仅通过中心数据库关联起来，因此我们可以通过设置多个代理和扫描器地随意组合来实现分布式地批量检测。

这种设计架构可以很方便地进行扩展和应用， 例如：

  • 对于漏洞检测或者安全测试人员，我们只需要在本地设置好代理（如：burp），然后在浏览器或者移动APP中正常地访问或者测试应用的每一个页面和功能，接下来的漏洞检测工作就完全交给了扫描器去做，这将极大地节约了时间和避免了大量重复的手工检测的工作量
  • 对于企业系统，我们可以将代理设置在应用前端（如：load balancer），这样所有的请求将会被自动镜像在扫描数据库，并自动分发给多个扫描引擎进行检测，无需手工干预即可发现很多隐藏很深的漏洞

0x02 实践

俗语说的好，“Talk is cheap, show me the code”! 是的，为了更好地了解这种设计思路的好处，笔者设计了一个Demo系统。该系统利用了burp作为代理，当我们在浏览器或者手机的wifi中配置好了代理服务器，漏洞检测的工作将会简化成简单地浏览应用的每一个页面和功能，代理将会自动地收集产生的所有请求数据（包括，各种请求头，cookie，请求方法，请求数据等）然后通过解析器的解析并存储于中央数据库，然后再分发于多个扫描引擎对请求的所有可控输入点进行repeat检测。

效果如下：

以下是我封装的一个python的requests库，它支持发送自定义的cookie，headers的get/post的请求，并可以是使用PhantomJS引擎去解析和渲染GET请求响应的页面中的javascript，css等，可以非常方便的应用于反爬虫和DOM型XSS的检测。

Code：https://github.com/brianwrf/HackRequests

0x03 思考

从漏洞检测的角度来说，经过笔者的测试（以DVWA和WebGoat为例）检测效果还是非常明显和有效的。其实这种类似的设计，很早之前就已经有人做了，那么很多人要问了为什么你还要在重复造个轮子呢？其实原因有以下几点：

  • 系统耦合性较强，不利于进行扩展和改造
  • 在HTTPS的流量捕获上支持的不是很好
  • 没有做到对HTTP请求中所有的可控输入点进行检测，例如，仅仅检测GET/POST数据，而对cookie，user-agent, referer等缺乏检测
  • 缺乏对于DOM的渲染和解析，容易造成对于基于DOM的漏洞的漏报，比如：DOM型的XSS等
  • 不具备分布式部署的能力，无法有效利用分布式处理的优点来提高检测效率
  • 不具备真正的意义上的repeat检测能力，换句话说不能完全模拟用户的请求

当然，上述的设计也存在一些待解决的问题，比如：

  • 若将代理部署至应用前端镜像所有请求，再分发至扫描引擎检测，如何防止真实用户数据泄漏和篡改？可能的解决方案是设置例外，对于敏感字段或者请求进行例外处理。

写在最后

Anyway, 新系统的设计无非是汲取前人的智慧加以优化再为后人铺路，解决问题才是考验系统能力的关键！后续我会继续努力改进其不足，让其更加易于使用！

注：如觉得有意思想转载的话，请注明出处，尊重知识产权，从你我开始，谢谢！