标签归档:Red Team

关于如何更好地呈现红蓝对抗价值的思考

虽然红蓝对抗机制和蓝军团队建设的经验和思考笔者已经通过不同渠道(博客、公众号、公开演讲等)多次分享了,但是今天这篇文章主要是谈一谈关于如何更好地呈现红蓝对抗的价值。

众所周知,近几年由于国家政府的重视红蓝对抗已经开始在国内各大组织和企业内蓬勃发展,但是笔者发现国内在运用红蓝对抗的价值呈现上还是有待提高的。纵观当前国内的情况,大家更重视这种形式的直接结果,如发现了几个漏洞之类的,却似乎很少公开提及如何将红蓝对抗更深次的价值呈现出来,这既包括横向上对防守团队的防御体系建设的促进,也包括纵向上对管理层的红蓝对抗价值呈现的理解。

笔者近年来一直在从事红蓝对抗机制和团队的建设,也在平时的工作中经常思考如何更好将红蓝对抗结果的价值呈现最大化,负责过蓝军建设的同学一定会或多或少被问到过类似的问题,即“红蓝对抗对企业到底有多大价值?如何量化体现?”。

一般的红蓝对抗的流程会在复盘阶段的《红蓝演练行动报告》和《复盘总结报告》中呈现红蓝对抗的结果价值,按照笔者的经验大多数情况下这两个报告一般会包括如下几方面内容:

  • 攻击过程与时间线
  • 发现的关键漏洞和修复建议
  • 发现的关键安全问题和改进建议

但是这些仅仅反映了单次红蓝演练行动中发现或者暴露的问题,而大多数情况下最终会被体现为演练过程中发现了哪些漏洞的问题。对于处于红蓝对抗演练初级或者早期阶段的企业或者组织来说,或许比较能给管理层带来短暂的震撼和重视,但是经历了多次演练后就可能会面临一些“漏洞审美疲劳”的问题,诸如:

  • 蓝军发现的这些漏洞是已知漏洞
  • 蓝军的这些攻击方式是已知攻击路径
  • 蓝军发现的这些安全问题是已知问题,且并不关键

那么如何避免由于将红蓝对抗的结果呈现单纯漏洞化而导致非蓝军人员或者管理层片面地以为红蓝对抗就是找漏洞的误解,笔者认为应该从红蓝对抗的本质出发,我们都知道以攻促防是红蓝对抗的本质,因此需要蓝军从业人员懂得从方法论设计、根因分析模型、数据量化分析等维度来深度呈现红蓝对抗的价值。

首先我们来看看国外同行是如何从这几个维度来实践的。

方法论设计

洛克希德马丁的Kill-Chain模型就是典型的红蓝对抗的方法论,其将攻击者的思考逻辑抽象成具体的攻击步骤,指导攻击者实施攻击,同时也帮助防守者理解攻击思维。

kill-chain

根因分析模型

MITRE的ATT&CK则是一个标准的根因分析模型,遵循Kill-Chain方法论通过解构攻击过程中具体的TTPs让不从事攻击的人员也可以理解攻击者思维及具体的攻击过程从而做到“知己知彼”。

attck

数据量化分析

FireEye的攻击生命周期模型是利用数据思维量化分析攻击过程中最容易被攻击者青睐的TOP攻击点从而为防守者提供防御投入的数据依据。
fe
fe2
通过研究和学习以上国外同行在红蓝对抗价值呈现的经验并结合自身的经历,笔者这几年也提出并实践了一套红蓝对抗价值呈现模型即红蓝对抗飞轮模型,并尝试将实战红蓝对抗演练行动解构成多个单点的攻击技术点,再通过数据统计方法挖掘防御的薄弱点,最后结合业界最佳实践提出针对性的防御体系改进建议。

红蓝对抗飞轮模型

红蓝对抗飞轮模型即实施红蓝对抗行动,从每次行动中梳理攻击路径,将攻击路径中的攻击技术点映射到MITRE的ATT&CK矩阵(也可以是组织或者企业内部自建的ATT&CK矩阵)中的TTPs上,根据映射后的攻击TTPs识别相应的安全问题,按照FireEye的攻击生命周期模型统计多次行动中的TTPs的使用频率或次数总结出共性安全问题,最后针对数据量化分析后的共性问题结合业界最佳实践提出改进建议。
fw

0x00 实施红蓝对抗、发现攻击路径

00

0x01 映射攻击TTPs、识别安全问题

01

0x02 统计共性问题

fw2
02

0x03 改进防御体系

03

根据该模型,我们便可以建立起一个包含了方法论设计、根因分析模型及数据量化分析为一体的红蓝对抗价值呈现体系。利用这一套体系建立起横向和纵向的价值呈现标准和语言,用数据量化体现红蓝对抗的价值。

云上攻防: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时会用到的工具:

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&CKAPT组织分析报告等来积累和学习这些真实攻击者的TTPs。其中一种流行的方法是,以ATT&CK Matrix和APT组织为参考,对具体的攻击技术细节进行分析和总结。

基础架构

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

  • 信息收集工具:如OSINT(Maltego,ShodanCensysGoogle DorksGithub,SNS等),企业邮箱和域名采集工具(The Harvester等),漏洞扫描器等;
  • Payload生成工具:如Cobalt Strike,Metasploit,Empire,DotNetToJScriptSharpShooterCACTUSTORCHmacro_pack等等;
  • C2架构:包括钓鱼与payload分发系统,基于各种协议(DNS,HTTP,ICMP)或者外部系统(Domain Fronting,Github,SNS等)的short-haul和long-haul C2,如: