标签归档:Red Teaming

云上攻防二三事(续)

云上攻防系列其实早在几年前笔者就公开分享过一些思路,有兴趣的可以看看Red Teaming for Cloud(云上攻防)

众所周知,云计算领域是一个融合众多软件技术及架构的领域因此也面临着各式各样的安全威胁,作为聚焦云上攻防的蓝军从业人员(Red Team)不仅需要掌握传统领域的渗透技能,也需要积极拓展思路,切忌画地为牢。

本文是通过对近期国外TOP3云厂商已公开攻击方法的洞察分析后的阶段性总结提炼。

AWS

GCP

Azure

小结

目前云上攻击的主要思路集中在以下几个层面:

  • 突破网络隔离:传统的网络隔离边界(防火墙、路由器、交换机、VPN)、VPC(peering、endpoint、traffic mirror)、云专线(混合云、多云网络)、安全组等;
  • 突破资源隔离:虚拟机逃逸、容器逃逸、物理机CPU/芯片侧信道攻击等;
  • 突破权限隔离:IAM账号(AWS Landing Zone)、IAM策略(ABAC)、委托代理、联邦认证(AWS STS security tokens、SAML)等;
  • 突破架构隔离:物理多租(单租户独享)、逻辑多租(多租户共享)等。

参考

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

基于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安全威胁的有效方法之一。

参考

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,如:

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

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执行链添加新的入侵检测规则.

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