标签归档:云安全

从云上攻防态势分析展望云服务安全架构设计框架发展

本文主要是记录笔者基于近期对云上攻防态势的分析思考和展望云服务安全架构设计框架的未来发展趋势,观点仅代表个人。

云上攻防态势分析

近期,笔者详细分析了近几年所有公开的云厂商漏洞报告[1]发现,头部云厂商的云服务都存在不少漏洞,其中AWS、GCP、Azure被公开披露的云服务漏洞最多。
01

其中最易受攻击的云服务类型主要集中以下几种类型:
02

  • k8s/容器:AWS CloudShell, AWS ECR Public, AWS ECS, AWS EKS, Azure ACI, Azure Function Apps, Azure Service Fabric, Azure CloudShell, GCP Anthos Service Mesh, GCP Cloud Shell, GCP GKE
  • 数据库:AWS RDS, Azure Cosmos DB, Azure Database for PostgreSQL, GCP Cloud SQL, IBM Cloud Database for PostgreSQL, Aliyun ApsaraDB RDS for PostgreSQL, Aliyun AnalyticDB for PostgreSQL
  • 数据管理:AWS AppSync, AWS Glue, Azure Cognitive Search, Azure Synapse Analytics, Azure Data Factory, GCP Dataflow
  • CI/CD:AWS CodeStar, Azure DevOps, Azure Service Fabric Explorer, GCP CloudBuild
  • 计算:Azure Red Hat Update Appliance, GCP GCE, GCP GCD, GCP OS Login
  • IAM:AWS IAM, Azure AD, Azure ADFS, GCP IAM

由此可见,大量基于k8s/容器等新技术构建的云服务是攻击者/安全研究者最青睐的攻击/研究对象,其次就是近年来针对基于开源数据库软件构建的云数据库和数据管理服务的攻击趋势明显上升,此外针对CI/CD云服务的供应链攻击也在显著增多,还有针对最常见的云上IAM服务的攻击依然普遍存在。

进一步分析发现云服务面临的主要攻击类型如下:
03

  • 越权攻击:
    • Azure  Cosmos DB Notebook的forwardingId存在越权问题可导致RCE漏洞(CosMiss)
    • GoldenSAML攻击主要针对联邦认证机制中使用的SAML  Response的伪造
    • 利用assume  role提权至Glue服务账号再结合其内部API的不安全配置获得其他使用了Glue服务的租户账号权限
    • 利用AWS  AppSync服务的confused deputy问题实现跨租户资源访问
    • 利用AWS  ECR Public服务的未公开API跨租户越权修改容器镜像
    • 利用Azure  PostgreSQL权限配置不当实现本地提权及通过数据库备份功能证书校验逻辑不严实现跨账号数据库认证绕过
    • 利用GCP  CloudBuild服务的Service Account账号的token(metatdata  API中获取)实现IAM的提权,即利用云服务的默认过多的IAM权限实现IAM的低权限提升
    • 利用GCP的各种服务特性实现IAM权限提升,即间接提权方式
    • 利用云服务的跨账号默认IAM权限配置不当,如允许修改资源arn,实现跨租户资源获取
    • 在Azure  Synapse Spark功能中利用filesharemount.sh脚本的条件竞争问题对任意文件执行chown操作从而实现本地提权
  • 注⼊攻击:
    • AWS  SageMaker Jupyter Notebook Instance  Takeover(利用XSS->CSRF->安全恶意扩展->访问Metadata->获取AWS认证token)
    • Azure  Synapse pipelines and Azure Data Factory默认使用的第三方适配Amazon  Redshift的ODBC连接器驱动存在命令注入漏洞(CVE-2022-29972)导致RCE可获取Azure服务敏感信息和跨租户数据
    • Google  Cloud Shell – Command Injection
    • 利用AWS  PostgreSQL的log_fdw扩展的路径穿越漏洞实现任意本地文件读取泄露RDS服务的内部认证凭据
    • 利用CSTI和存储型XSS获得Azure  Service Fabric Explorer服务的用户管理员权限(CVE-2022-35829)
    • 利用Google  Cloud Shell校验逻辑不当借助Theia IDE实现Cloud Shell命令注入可绕过安全校验直接访问Cloud  Shell底层VM实例的metadata
    • 利用Kudo提供的SCM面板的CSRF攻击多个Azure  Web服务
    • 通过commit  message修改Azure DevOps流水线执行过程中的环境变量可导致软件供应链攻击
    • 通过SSH公钥注入获取GCE访问权限
  • 云原⽣攻击:
    • Azure  Container Instances (ACI)服务跨账号容器接管
    • PostgreSQL服务帐户可以访问其他 RDS(MySQL、SQL Server 等)的 Docker 映像
    • 利用AWS的ECS服务的Task  Definition新建容器并通过EC2的metadata API获取临时AK/SK提权
    • 利用Azure  Serverless Function容器中本地进程提权实现容器逃逸
    • 利用Google-managed  Anthos Service Mesh的Istio控制面支持多集群部署通过新建恶意的GKE集群并部署Google-managed  ASM导致RCE可直接访问Google-managed ASM底层VM实例的metadata
    • 利用k8s  TLS Bootstapping机制进行提权
    • 利用具有CAP_NET_RAW  Linux  capability和hostNetwork=true的容器通过中间人劫持K8S集群的云宿主机node节点上的Metadata服务实现本地提权或者容器逃逸
    • 通过AWS  ECS Task Definition可以获取敏感信息(Task Definition类似于k8s的kubeconfig文件)
    • 阿里云PostgreSQL服务因不安全配置导致容器逃逸可造成跨租户数据库的未授权访问
  • 信息泄露:
    • AWS:  Lightsail object storage access keys logged
    • GCP:  Exfiltrate data via the logs of GCP Org policy
    • NotLegit:  Azure App Service vulnerability exposed hundreds of source code repositories
    • S3漏洞利用(计算资源中列权限、过度依赖IAM防止数据泄露、非公开的桶中包含公开的存储对象)
    • 滥用AWS  VPC服务的TrafficMirror特性获取东西向流量中的敏感信息
  • 开源组件攻击:
    • AWS  CloudShell Terminal(Cloud9)命令注入漏洞(CVE-2019-0542)
    • AWS:  In-band key negotiation issue in the AWS S3 Crypto SDK for golang  (CVE-2020-8912 and CVE-2020-8911)
    • Azure:  Cloudshell terminal escape (CVE-2019-0542)
    • Dataflow服务的JMX  RMI端口未授权访问导致RCE并借助使用host网络的容器可直接访问GCE的metadata
  • 防御绕过:
    • 利用AWS  API Gateway服务可以绕过IP黑名单的限制
    • 利用未公开的私有API绕过CloudTrail的日志记录

通过分析以上针对云服务的攻击类型可以总结出云服务面临的主要威胁类型(STRIDE)如下所示:

04

根据识别出来的云服务面临的主要威胁,站在云服务安全架构设计的角度来看导致这些安全威胁的根因应该包括以下几个方面:

  • 网络连接:突破云服务所在的网络隔离直接攻击云服务
    • 传统的网络隔离边界:防火墙、路由器、交换机、VPN
    • VPC:peering、endpoint、traffic mirror
    • 云专线:混合云、多云网络
    • 安全组
  • 部署模式:利用云服务部署架构的特性打破租户隔离实现跨租户资源获取
    • 物理多租:单租户独享
    • 逻辑多租:多租户共享
  • 资源负载:利用部署云服务的资源负载的逃逸漏洞突破资源隔离
    • k8s/容器逃逸
    • 虚拟机逃逸
    • 物理机CPU/芯片侧信道攻击
  • 权限配置:利用云服务的权限策略配置问题突破权限隔离
    • IAM账号:AWS Landing Zone
    • IAM策略:ABAC
    • 委托代理:Confused Deputy
    • 联邦认证:AWS STS security tokens、SAML
  • 服务功能:利用云服务自身功能特性和漏洞造成资源滥用、权限提升、信息泄漏
    • 传统的Web漏洞:SSRF、XXE、XSS、CSRF、CSTI
    • 云服务功能滥用:API Gateway、CloudShell Terminal、云函数、云WAF、云CDN、云存储桶
    • 未公开API滥用
  • 应用数据:不安全的应用数据保护导致信息泄漏
    • 云日志服务:CloudTrail
    • 数字证书不当传输与保存:Azure AD、Cloud SQL Auth Proxy
    • 数据明文传输与保存:VPC TrafficMirror

业界云服务安全架构设计方法论

云安全公司Wiz近期发布了一个专门针对云服务租户隔离框架PEACH,结合其在云安全领域的研究成果系统地提出了云服务安全架构设计方法论[3]。

Wiz认为典型的云服务漏洞引发的跨租户攻击模式如下:
05
应用PEACH框架构建安全的云服务架构的核心原则包括:

  • 减少云服务应用接口的复杂性
  • 增强租户间资源访问的隔离性
  • 提高租户间资源的冗余度

具体分两步走:

第一步,对云服务应用进行威胁建模

06
1) 首先找出云服务应用的所有外部接口。
2) 然后对每个接口执行以下分析:
07
2.1) 确定输入类型(即输入的不受信任的数据)和接口的各个组件。
2.2) 绘制接口的设计图,包括以下元素:
08
  • 注意用户输入类型,可能会变形以滥用接口。
  • 跟踪数据从用户输入经过的每个存储或处理它的组件的流程。
  • 区分共享和复制组件。
  • 添加安全边界,将每个复制组件与其他租户分开。
2.3) 评估每个组件的复杂度级别。
2.4) 根据以下准则确定接口的隔离级别:
  • 使用了哪些安全边界类型?
    • 资源隔离
    • 数据隔离
    • 网络隔离
    • 身份隔离
  • 它们彼此独立吗?
    • 共享组件
    • 复制组件
  • 它们如何加固?(参见第二步)
    • 权限加固
    • 加密加固
    • 认证加固
    • 网络加固
    • 环境清理
2.5) 在实施表中总结发现的威胁。
09
2.6) 通过询问来确定数据流的每个阶段可能出现的潜在漏洞:
  • 组件的攻击面是什么?
  • 什么样的恶意用户输入可能导致滥用?

2.7) 如果隔离级别在复杂性和情境因素(包括合规性、数据敏感度和预算考虑)方面被确定为不足,则根据需要修改设计,通过减少复杂性,增强隔离性,增加资源冗余度来提高隔离级别。

第二步,基于P.E.A.C.H.五个方面实施云服务安全加固

  • 权限加固(Privilege hardening):
    • 在服务环境中,租户和主机通常具有最小的权限,遵循最小特权原则。
    • 特别地,除非经过租户明确批准,否则每个租户不得读取或写入其他租户的数据,每个主机也不能读取或写入其他主机的数据
    • 在执行操作之前,需要验证权限。
  • 加密加固(Encryption hardening):
    • 属于每个租户的数据(静态数据和传输数据)都使用唯一于该租户的密钥进行加密,而不管架构如何。
    • 与每个租户的活动相关的日志由租户和控制平面之间共享的秘密进行加密。
  • 认证加固(Authentication hardening):
    • 每个租户与控制平面之间的通信(双向)使用唯一于每个租户的密钥或证书进行身份验证。
    • 验证身份、验证密钥,并阻止使用自签名密钥。
  • 网络加固(Connectivity hardening):
    • 默认情况下,除非经过租户明确批准(例如便于数据库复制),否则阻止所有主机之间的互联互通;主机不能连接服务环境中的其他主机,除了控制平面使用的主机(即集线器和分支配置)。
    • 除非经过租户明确批准,否则主机不接受来自其他主机的传入连接请求,除了控制平面使用的主机(以防攻击者设法克服自己受损主机上的连接限制)。
    • 租户不能随意访问任何外部资源(服务环境内部和Internet上的资源),只能与租户预先批准或明确批准的资源进行通信。
  • 环境清理(Hygiene):环境中的不必要的数据或者信息可能为攻击者提供线索或快速收益,特别是那些已经成功攻破一个或多个安全边界的攻击者,这会进一步促进侦察和横向移动。因此,供应商可以在设计阶段消除以下类型的数据,并定期扫描部署环境中遗忘的数据或者信息:
    • 机密信息:接口和数据存储(以及虚拟化或容器化情况下的底层主机)不包含任何密钥或凭据,这些凭据将允许对其他租户环境进行身份验证或解密其他租户的后端通信或日志。
    • 软件:主机实例和数据存储(以及底层主机)不包含任何内置软件或源代码,这些软件或源代码可能会促进侦察或横向移动。
    • 日志:每个租户的日志对其他租户隐藏并不可访问;每个租户可访问的日志不包含与其他租户活动有关的任何信息。

新型云服务安全架构设计框架

应该说PEACH框架是一个不错的云服务安全架构设计框架,但是细究下来也存在一些不足:

  • 过度隔离:为了提高资源冗余度添加太多重复组件和安全边界也可能会导致云服务环境整体复杂度的增加,从而可能引入新的漏洞。
  • 过度依赖人的分析经验:云服务安全架构师需要具备丰富的攻防经验,了解各种云服务接口类型和相应的加固方案,过度依赖架构师的经验会导致不同能力的架构师对于风险消减的最终效果差异较大。

因此,结合云上攻防态势分析的结果和PEACH框架的核心思想,笔者提出了一种新型的云服务安全架构设计框架(LSSA)。

第一步,将云服务按照关键架构元素进行梳理10

  • 网络连接:梳理出云服务各组件与底层资源、及与其他服务的网络连接方式。
  • 部署模式:梳理出云服务资源的部署方式,如逻辑多租或者物理多租。
  • 资源负载:梳理出云服务应用运行的工作负载,如虚拟主机、容器、或者裸金属主机等。
  • 权限配置:梳理出云服务自身及各组件间的身份认证与鉴权方式及相应的配置。
  • 服务功能:梳理出云服务自身业务的各种功能特性,如面向互联网的API网关、云存储桶、云函数等。
  • 应用数据:梳理出云服务应用处理和保存的各类租户及云服务自身的数据类型,如租户日志、云服务数字证书等。

第二步,针对每一个关键架构元素进行风险识别和安全加固

首先,根据历史上公开的云服务漏洞整理出每一个关键架构元素的威胁知识库:
11
Picture1
然后,对照威胁知识库针对每一个关键架构元素按照以下核心原则识别潜在风险并进行相应的安全加固。
  • 最小权限(Least Privilege):确保云服务自身及各组件间的身份认证与鉴权始终保持满足业务需要的最小权限。
  • 增强隔离(Improve Separation):从资源隔离(裸金属、虚拟机、容器)、网络隔离(专线、VPC、安全组)、身份隔离(IAM、MTLS、数字证书、联邦认证、委托授权、零信任鉴权)、架构隔离(专属集群、专属region、专属AZ、物理多租)、数据隔离(传输与存储加密、一租户一密)等方面增强租户间的隔离水平。
  • 默认简单(Simplify by default):云服务接口的功能设计要默认简单,每一个对外接口尽可能只做一件事,正如Unix哲学及其实现“一个程序只做一件事,并做好”。
  • 假定失馅(Assume Breach):在审视每一个关键架构元素的风险时,要思考如果当前的架构元素被攻击者控制后最坏情况下能造成哪些重大影响(也就是爆炸半径),影响当前的云服务架构元素?其他的云服务架构元素?还是其他的云服务?

参考

云上攻防二三事(续)

云上攻防系列其实早在几年前笔者就公开分享过一些思路,有兴趣的可以看看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时会用到的工具: