一、从集群打到 CI/CD 前五篇走完，手上已经有了一张集群管理员权限和一个云账号。接下来最有价值的目标是 CI/CD，原因是它是凭证密度最高的地方。 一个 CI Runner 上通常同时存在：拉代码的凭据、推镜像的凭据、部署到 K8s 的 kubeconfig、部署到云的 AK/SK、各种第三方服务的 token。控制了一个 Runner，等于拿…

一、先画一张集群的攻击面地图 K8s 集群渗透和传统内网渗透最大的区别是：内网渗透从"扫端口"开始，集群渗透从"我是谁、我有什么权限"开始。因为集群里大量接口默认就是给内部组件互相调用的，认证和授权经常配得比对外服务松。 1.1 组件与端口 先把要盯的端口列清楚： 端口组件用途常见问题6443kube-apiserver集群唯一的 API 入口匿名…

一、逃逸之前先搞清楚自己在哪 容器逃逸最常见的问题不是手法不够，是上来就跑错 payload。看到一个 --privileged 的容器就急着挂盘，结果发现根本没有块设备；看到一个普通容器就放弃了，其实 /proc/sys 是可写的。 这一节的目标是：拿到一个容器内的 shell 之后，用三十秒把"我在什么容器里、有什么能力、缺什么"判断清楚，然后…

一、拿到凭证之后第一件事是枚举，不是利用 第一篇从代码仓库和对象存储里捞到了 AK/SK，第二篇从元数据服务里拿到了临时凭证。现在手上有一组凭证，接下来做什么？ 大部分人的第一反应是"试试能不能 create user"。这个顺序是错的。正确的顺序是：先花二十分钟把这组凭证的权限摸清楚，再决定打哪条路径。 原因很实际。云 IAM 的权限是叠加的：用…

一、元数据服务是云上最值钱的一个地址 第一篇讲了怎么找云资产和泄露的凭证。这一篇讲另一条更常见的路径：不依赖任何外部泄露，仅凭目标服务器上的一个 SSRF，直接拿到云账号的临时凭证。 这条路径的入口是一个地址：169.254.169.254。 1.1 为什么是这个地址 云厂商为了让实例里的程序能免密调用云 API，在每个实例内部提供了一个 HTTP…

一、云渗透和传统渗透不是同一套方法论 先说结论：云上渗透的起点通常是一组凭证，而不是一个 IP 段。 做过 Web 渗透的人第一次做云测评，最容易犯的错是打开 nmap 扫 C 段。扫完发现全是 443 和 80，返回的还是云厂商的负载均衡，看起来毫无破绽，然后就卡住了。原因是云环境的攻击面根本不在端口上： 维度传统 IDC 渗透云环境渗透入口IP…