1. 项目概述：从红队视角看云上攻防
最近几年，云安全的话题越来越热，但很多讨论都集中在防御方（蓝队）的视角，比如如何配置安全组、如何做审计。作为一名长期在一线参与攻防演练和渗透测试的红队成员，我反而觉得，真正理解攻击者的思路，才是构建有效防御的起点。今天，我就结合自己多次在授权范围内对云环境进行安全评估的经验，来拆解一下针对主流云服务——特别是阿里云的ECS（弹性计算服务）和RDS（关系型数据库服务）——的实战渗透流程与核心思路。
这绝不是一份“黑客教程”，而是一份“攻击者思维指南”。我们的目标是通过模拟攻击路径，揭示云服务在配置不当或存在脆弱点时可能面临的风险，从而帮助云架构师、安全运维和开发人员更好地理解威胁全貌，加固自己的云上资产。无论是准备参加像“vulnstack红队5”这类综合靶场演练，还是研读《Web安全攻防渗透指南》这类经典书籍，对云环境的理解都已成为不可或缺的一环。很多人以为上了云就万事大吉，把服务器托管给阿里云、数据库用上RDS就高枕无忧，实则不然。云服务提供商（CSP）负责的是“云本身的安全”（Security of the Cloud），而“云内部的安全”（Security in the Cloud）——即你怎么配置和使用这些服务——责任完全在客户自己身上。
2. 红队云渗透的核心思路与前置侦察
在针对云环境的渗透中，盲目扫描端口和Web漏洞是效率最低下的方式。云环境有其特殊性，我们的思路必须转变：从“攻击一台服务器”转变为“攻击一个云租户的整个资源体系”。核心目标往往是获取足够高的权限（如子账户AK/SK、临时令牌、控制台权限），进而横向移动，控制更多资源。
2.1 信息收集：超越IP与域名
传统的渗透从域名和IP开始，云渗透则需要关注更广的维度。
1. 资产发现与测绘： 云上资产往往是动态的，IP地址可能变化，但资源名称、标签、实例ID是相对稳定的标识。红队初期会利用公开信息进行搜集：
-
子域名枚举：
目标公司使用的业务系统很可能部署在云上，通过子域名爆破（如
*.oss-cn-hangzhou.aliyuncs.com指向对象存储）、证书透明度日志（CT Log）查询，可以发现关联的云服务端点。 -
网络空间测绘：
使用
fofa、shodan、zoomeye等平台，搜索与目标公司相关的特征，例如特定的云服务内部域名、Bucket名称、代码仓库中泄露的云服务地域（Region）信息等。搜索语法如title="阿里云" && org="目标公司"或port="6379" && cloud.service.name="阿里云"。 -
GitHub等代码仓库监控：
这是云凭据泄露的重灾区。搜索目标公司的代码仓库，关键词包括
accessKeyId,secretAccessKey,AKIA,oss.aliyuncs.com,rds.aliyuncs.com,ecs.aliyuncs.com等。一个泄露的AK/SK可能直接打开通往整个云资源的大门。
2. 识别云服务提供商与架构：
确定目标使用的是阿里云、腾讯云还是AWS等，这决定了后续攻击利用的工具链和API接口。通过前面收集的域名（如
*.aliyuncs.com
）、IP段（查询IP归属）可以快速判断。进一步，需要判断其云上架构：
- 是否使用VPC（专有网络）？ 大部分企业级应用都会部署在VPC内，这意味着从互联网无法直接访问其ECS的私网IP。攻击入口点通常集中在公网暴露的资产上，如Web服务器、API网关、负载均衡（SLB）、NAT网关后的机器等。
- 网络拓扑推测： 通过扫描有限的公网IP，分析开放端口和服务，可以推测其网络结构。例如，发现一个服务器同时开放了80/443端口和22端口，它很可能是一个放在公网网段的跳板机或前端应用服务器。
实操心得： 在针对云环境的侦察中，我习惯建立一个“资产关系图谱”。不仅仅记录IP和端口，更记录这个资源是ECS、RDS、OSS还是SLB，它属于哪个VPC，安全组规则大概是什么样（通过有限的探测推测），哪些资源之间可能存在内网访问关系。这张图会随着渗透深入不断丰富，是指引横向移动的“地图”。
2.2 初始突破：寻找薄弱入口
云环境的初始突破点往往和传统环境类似，但云服务的特性会带来一些新的攻击面。
1. Web应用漏洞： 这是最经典的入口。无论应用部署在本地IDC还是云上ECS，SQL注入、文件上传、RCE、反序列化等漏洞依然有效。攻破一台部署在云ECS上的Web服务器，你就获得了一个在云VPC内部的立足点。
-
关键动作：
获取Shell后，第一时间检查实例元数据。云平台通常提供一个内部端点，用于ECS实例获取自身的配置信息，其中可能包含临时访问凭证（STS Token）。对于阿里云，这个端点通常是
http://100.100.100.200/latest/meta-data/。如果服务器配置了RAM角色，访问http://100.100.100.200/latest/meta-data/ram/security-credentials/<RoleName>就能拿到具有该角色权限的临时AK/SK。 - 漏洞利用结合云特性： 例如，通过文件上传漏洞上传一个Webshell，再利用Webshell执行命令访问元数据服务。或者，在SSRF（服务器端请求伪造）漏洞中，利用其访问元数据服务，直接窃取凭证。
2. 不当暴露的服务与组件： 云上常会部署一些用于管理、监控、中间件的服务，如果配置不当，可直接导致入侵。
-
Redis未授权访问：
云上ECS部署的Redis如果绑定在
0.0.0.0且未设置密码，可直接连入。利用Redis写Webshell、写SSH公钥、主从复制RCE都是常见手段。更危险的是，如果这台Redis在VPC内，且与其它重要资源（如RDS）网络互通，攻击者可以将其作为跳板，进一步攻击内网。 - Docker API未授权： 如果ECS上Docker守护进程的2375端口暴露，可远程管理容器，直接部署恶意容器或逃逸到宿主机。
- K8s API Server暴露： 同理，如果Kubernetes的API Server端口（6443）暴露且认证薄弱，可控制整个集群。
- 各类运维服务： 如Jenkins、Ansible Tower、GitLab等，若存在弱口令或漏洞，可直接获取服务器权限或代码仓库权限，后者可能泄露云凭据。
3. 凭据泄露与错误配置： 这是云安全独有的、也是最高效的突破方式。
-
AK/SK泄露：
如前所述，在代码、配置文件、甚至是前端JS文件中找到AccessKey。拿到AK/SK后，可以使用阿里云命令行工具
aliyun CLI或SDK直接调用API，权限取决于该AK关联的RAM用户或角色所具有的权限。 - OSS Bucket公开读写： 对象存储服务（OSS）的Bucket如果被配置为“公共读写”或“公共读”，攻击者可以直接列出、下载所有文件，甚至上传恶意文件。Bucket里可能存放着源代码、配置文件、数据库备份、访问日志等敏感信息。
-
RDS公网访问与弱口令：
虽然不推荐，但有些用户为了便捷，为RDS实例开启了公网访问地址。如果此时数据库账号密码是弱口令（如
root/123456），或者存在SQL注入点能获取到连接信息，攻击者就可以像连接本地数据库一样，使用Navicat、MySQL Workbench等工具直接连接，进行拖库、篡改等操作。
3. 横向移动与权限提升：在云VPC内漫游
一旦获得了一个初始立足点（一台ECS的Shell，或一组有效的AK/SK），红队的工作重点就转向在云环境内部进行横向移动和权限提升，目标是控制更多核心资源，特别是数据。
3.1 利用实例元数据服务与RAM角色
这是云上横向移动的“杀手锏”。如果被你攻陷的ECS实例被授予了某个RAM角色（Instance Role），那么通过访问实例元数据服务，你就可以获得一组临时的安全令牌（STS Token）。这组令牌的权限等于该RAM角色的权限。
操作流程：
-
检查元数据：
在已控的ECS上执行
curl http://100.100.100.200/latest/meta-data/，查看可用信息。 -
获取角色名：
访问
http://100.100.100.200/latest/meta-data/ram/security-credentials/，它会列出附加到此实例的RAM角色名称。 -
窃取临时凭证：
访问
http://100.100.100.200/latest/meta-data/ram/security-credentials/<RoleName>，返回的JSON数据中包含AccessKeyId,AccessKeySecret,SecurityToken。 -
利用凭证：
使用这些凭证配置
aliyun CLI。aliyun configure set --profile hacked-role \ --region cn-hangzhou \ --access-key-id STS.NTcyxxxxxxxx \ --access-key-secret xxxxxxxxx \ --sts-token CAIS+wxxxxxxxxxxxxxxxxxx -
探测权限：
使用配置好的profile执行命令，探测该角色的权限边界。例如，尝试列出ECS实例、RDS实例、OSS Bucket等。
aliyun ecs DescribeInstances --profile hacked-role aliyun rds DescribeDBInstances --profile hacked-role aliyun oss ls --profile hacked-role
权限提升场景：
-
过度授权的角色：
角色可能被授予了
AliyunECSFullAccess、AliyunRDSFullAccess甚至AdministratorAccess。拿到这种角色的令牌，就等于控制了整个云账户下的对应资源。 - 利用角色访问其他服务： 即使角色权限不大，也可能有特定资源的访问权。例如，一个用于备份的角色可能有权限读取某个RDS实例，或者向某个OSS Bucket写入文件。
注意事项： 临时凭证通常有效期为1-6小时，需要定时刷新。在实战中，我们会编写脚本自动获取并更新凭证，维持访问。同时，云平台的安全审计（如ActionTrail）会记录API调用，但攻击者可以利用获取的权限尝试关闭或删除审计日志，抹除痕迹，这本身就是权限提升和持久化的一部分。
3.2 内网侦察与端口扫描
获得云VPC内部的一个节点后，需要对其进行深入侦察，绘制内网地图。
-
网络信息收集：
-
ifconfig / ip addr：查看当前机器的内网IP，判断其所在的网段（如172.16.0.0/16）。 -
netstat -antp：查看当前连接和监听端口，判断这台机器与哪些内网IP有通信，可能发现数据库、缓存、中间件等。 -
cat /etc/hosts：查看主机文件，可能包含内部域名解析记录。 -
cat /etc/resolv.conf：查看DNS服务器，云VPC内通常有默认的DNS（如100.100.2.136），可用于解析内部服务域名（如RDS的内网连接地址）。
-
-
内网端口扫描： 由于在云VPC内，安全组规则通常比公网宽松得多。可以使用
nmap,masscan等工具对内网网段进行快速扫描。# 扫描C段存活主机 nmap -sn 172.16.1.0/24 # 扫描常见端口 nmap -sS -p 22,80,443,3306,6379,8080,9000 172.16.1.0/24重点端口：
-
3306：MySQL (RDS) -
6379：Redis -
1433：SQL Server -
5432：PostgreSQL -
27017：MongoDB -
9200：Elasticsearch -
11211：Memcached -
445, 139：SMB (Windows文件共享)
-
-
利用云厂商工具/API侦察： 如果拿到了具有相应权限的AK/SK，直接调用云API是最高效的侦察方式，可以“上帝视角”查看资源。
-
列出所有ECS实例：
aliyun ecs DescribeInstances --RegionId cn-hangzhou -
列出所有RDS实例：
aliyun rds DescribeDBInstances --RegionId cn-hangzhou -
查看安全组规则：
aliyun ecs DescribeSecurityGroupAttribute --SecurityGroupId sg-xxx。分析入方向规则，可以知道哪些IP/网段可以访问哪些端口，为下一步横向移动提供路径。 -
查看VPC和交换机信息：
aliyun vpc DescribeVpcs，aliyun vpc DescribeVSwitches
-
列出所有ECS实例：
3.3 攻陷数据库（RDS）实战路径
RDS是核心数据资产，通常是红队的终极目标之一。从云内网访问RDS，通常比从公网容易得多。
路径一：利用应用服务器连接信息
- 攻陷一台Web应用服务器。
-
在服务器上查找数据库配置文件，如
application.properties,config.php,web.config等，获取RDS的内网连接地址、端口、用户名和密码。 -
直接使用
mysql -h <rds-internal-address> -u <user> -p进行连接。
路径二：利用备份或运维服务器
- 发现一台用于数据库备份或运维的ECS。
- 该服务器上很可能存有数据库连接凭证，或者配置了免密访问（如通过SSL证书或RAM角色认证）。
- 从该服务器连接RDS。
路径三：利用高权限AK/SK直接管理RDS
如果获取的RAM角色或AK/SK具有RDS管理权限（如
AliyunRDSFullAccess
），攻击者甚至不需要知道数据库密码。
-
通过API重置RDS实例的root/master密码。
aliyun rds ResetAccountPassword --DBInstanceId rm-xxxx --AccountName root --AccountPassword 'NewH@ckP@ss!' -
如果RDS原本没有开通公网地址，可以为其申请一个公网连接地址，方便外部直接连接。
aliyun rds AllocateInstancePublicConnection --DBInstanceId rm-xxxx --ConnectionStringPrefix 'hacked-db' --Port 3306 - 使用新密码和公网地址，通过Navicat等工具连接，进行数据导出、篡改或破坏。
路径四：从数据库到服务器
在某些架构中，数据库可能有权限通过函数或插件执行系统命令（如MySQL的
sys_exec
，但云RDS通常严格限制）。更常见的是，通过数据库中的敏感信息（如其他系统的密码、AK/SK），发起新的攻击链。
实操心得： 连接RDS后，不要急于拖库。先花时间进行“数据库内侦察”。查看有哪些数据库、哪些表，特别是寻找存放用户凭证、会话信息、配置信息的表。查看数据库中的存储过程、函数、事件，有时会发现意外的业务逻辑或硬编码的密钥。同时，检查
mysql.user表，看是否有高权限用户可以从其他IP登录，这可能是通往其他系统的跳板。
4. 权限维持与防御规避
在云环境中，取得权限后如何保持隐蔽、长期控制，是红队演练的进阶课题。同时，了解这些手法，也能帮助蓝队更好地部署检测策略。
4.1 后门持久化手法
-
ECS实例后门：
-
Webshell：
在Web目录下植入隐蔽的Webshell，利用
.user.ini、.htaccess等文件进行隐藏和自启动。 -
SSH后门：
修改
~/.ssh/authorized_keys，添加攻击者的公钥；或者安装SSH wrapper后门。 - 定时任务（Cron）： 添加定时任务，定期从远程服务器下载并执行恶意脚本，实现心跳和命令控制。
- 系统服务后门： 创建新的systemd服务或修改现有服务，使其在开机时执行恶意命令。
- 云助手后门： 阿里云ECS的“云助手”是一个在实例内部运行的代理，用于执行命令。如果攻击者获得了足够权限，可以尝试篡改云助手的相关配置或脚本，但此操作风险高，容易被安全软件检测。
-
Webshell：
在Web目录下植入隐蔽的Webshell，利用
-
利用云服务特性的持久化：
- 创建后门镜像： 如果拥有ECS管理权限，可以对一台已控的ECS实例创建自定义镜像（Snapshot）。以后可以通过这个镜像创建新的实例，新实例将自带所有后门。
- 用户数据（User Data）注入： 在创建或修改ECS实例时，可以通过“用户数据”传递启动脚本。攻击者可以修改实例属性，在用户数据中插入恶意脚本，实例每次重启都会执行。
- 对象存储（OSS）托管恶意脚本： 将后门脚本上传到OSS（可以是自己的Bucket，也可以是目标一个不公开的Bucket），然后在目标ECS的定时任务中，使用内网地址（避免流量审计）定期下载执行。这种方式隐蔽性好，难以在主机层面直接发现恶意文件。
-
RDS层面的持久化（较难但存在）：
- 数据库触发器（Trigger）： 在关键表上创建触发器，当数据被查询或修改时，触发器执行一段恶意代码（如调用一个可以外联的存储过程）。但这需要数据库本身支持外部命令调用，云RDS通常禁用此类高危功能。
- 存储过程/函数后门： 创建恶意存储过程，并将其与合法的业务功能关联。当应用调用某个正常功能时，恶意代码也被执行。
- 数据隐匿： 将控制命令或恶意Payload加密后存储在正常的业务表字段中，通过数据库的查询操作来解码和执行。这更像是一种C2通信的隐蔽信道。
4.2 防御规避与日志清理
云平台提供了强大的审计能力，如阿里云的ActionTrail（操作审计）、云监控、安全中心等。红队需要设法规避或干扰这些检测。
-
停止或删除审计日志：
如果获得了最高权限（如主账号或具有
AliyunActionTrailFullAccess的RAM用户），可以直接在控制台或通过API关闭ActionTrail，或者删除特定的审计日志轨迹。但这本身就是一种高危操作，会立即引发告警。 - 使用合法API进行隐蔽操作： 尽量使用目标环境中正常使用的服务和API进行横向移动。例如，如果运维常用ECS的“云助手”执行命令，那么红队也使用它，产生的日志会混在大量正常日志中，难以分辨。
- 利用受控资源做跳板： 所有攻击流量尽量通过已控的、目标环境内的ECS发起。避免从攻击者自己的IP直接调用云API或扫描端口。使用云VPC内的资源进行内网探测和攻击，流量特征更接近正常业务。
-
清理主机日志：
在已控的ECS上，清理
/var/log/目录下的安全相关日志（如auth.log,secure,lastlog,wtmp），以及Web访问日志、应用日志等。使用history -c清理当前用户的命令历史。 - 时间点选择： 在业务高峰期或运维活动频繁的时间段进行操作，产生的异常流量更容易被当作背景噪音。
注意事项： 在真实的授权渗透中，日志清理需要特别谨慎，并遵循演练规则。通常，蓝队会通过日志分析来发现攻击行为，红队的规避手段也是演练的一部分。但在非法攻击中，这些行为会加重罪行。对于防御方来说，必须确保审计日志被实时收集并存储在攻击者无法轻易删除的地方（例如另一个独立的云账号或日志服务SLS中），并设置多因素认证（MFA）保护关键管理账号。
5. 从攻击视角看云安全加固建议
经历了这么多攻击手法的拆解，我们反过来看，云上防御应该如何构建？这里从红队“最讨厌”遇到的安全配置角度，给出几点核心建议：
-
最小权限原则（PoLP）是基石：
- RAM用户/角色： 为每个应用、每个人、每项任务创建独立的RAM用户或角色，授予其完成工作所必需的最小权限。绝对不要使用主账号AK/SK进行日常操作。
-
避免使用系统策略：
AdministratorAccess、AliyunECSFullAccess这类宽泛的系统策略权限过大。尽量创建自定义策略，精确到Action（API操作）和Resource（资源ARN）。 - 实例角色（Instance Role）： 为ECS实例分配角色，而不是在实例中写死AK/SK。并通过策略限制该角色的权限，例如只允许读取某个特定的OSS Bucket，或只允许向某个日志项目写日志。
-
网络隔离与访问控制：
- 使用VPC并划分网段： 将Web层、应用层、数据层部署在不同的子网（VSwitch）中。
-
精细化安全组规则：
安全组应作为白名单。例如，Web服务器安全组只开放80/443端口给公网，3306端口只允许来自应用服务器安全组的流量。RDS实例的安全组只允许来自特定应用服务器安全组的流量访问3306端口。
坚决避免设置
0.0.0.0/0的入方向规则，除非是负载均衡器等前端服务。 - 限制RDS公网访问： 除非绝对必要，否则永远不要为RDS开通公网连接地址。业务访问一律通过内网。如果必须从公网管理，可以通过SSH隧道或数据库代理（如DMS）连接，而不是直接暴露。
- 利用网络ACL（如果需要）： 在子网级别进行额外的网络层访问控制。
-
敏感信息管理：
- 使用Secrets Manager： 将数据库密码、AK/SK、API密钥等敏感信息存入云厂商提供的密钥管理服务（如阿里云KMS/Secrets Manager），应用程序在运行时动态获取，而不是写在配置文件或代码里。
- 定期轮转凭据： 定期更换AK/SK、数据库密码、服务器密码。
- 代码扫描： 在代码提交前和CI/CD流程中，使用工具扫描代码仓库，防止AK/SK等硬编码信息被提交。
-
启用并保护审计与监控：
- 开启操作审计（ActionTrail）： 记录所有云API调用，并将日志投递到一个独立的、只有安全团队有只读权限的OSS Bucket或日志服务（SLS）项目中。
- 开启安全中心（云盾）： 启用主机防入侵、Web应用防火墙（WAF）、配置检查等功能。虽然攻击者可能尝试绕过，但能增加其攻击成本和被发现的风险。
- 部署主机级HIDS/EDR： 在ECS上安装主机安全代理，监控异常进程、文件改动、网络连接和提权行为。
-
监控异常API调用：
设置告警规则，例如：
ActionTrail中出现ResetAccountPassword、AllocateInstancePublicConnection、CreateSnapshot等高危操作时；安全组规则被修改；RAM策略被变更等。
-
加固应用与中间件：
- 及时打补丁： 确保ECS实例的操作系统、中间件（Redis, Nginx等）、应用框架保持最新。
- 非root运行： 应用程序、数据库、中间件服务都应使用非root用户运行。
- 配置安全基线： Redis设置强密码并禁用危险命令；Docker API不暴露在公网；K8s API Server启用强认证授权等。
云安全是一个责任共担模型。云厂商提供了坚固的“外墙”和丰富的安全工具，但墙内的安全，需要用户自己用心构建。红队演练的价值，就在于用攻击者的眼光，帮你检验这堵“内墙”是否处处漏风。希望这份从攻击视角出发的流程拆解，能给你带来不一样的启发，在设计和运维你的云上系统时，多问一句：“如果我是攻击者，我会从哪里进来？”
扫一扫
586
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
