k8s-kubeconfig泄露后的RBAC持久化后门排查

k8s-kubeconfig泄露后的RBAC持久化后门排查

攻击者
  │
  ├─ 1. 使用泄露 kubeconfig 连接公网 apiserver
  │
  ├─ 2. 创建后门 ServiceAccount(伪装成系统组件名)
  │
  ├─ 3. 创建 ClusterRole(全权限)
  │
  ├─ 4. 创建 ClusterRoleBinding(将后门 SA 绑定到 cluster-admin)
  │
  ├─ 5. 用 TokenRequest API 生成长期 token(不存储在 apiserver,难以追踪)
  │
  └─ 6. 防御方删除原始 kubeconfig 对应的 RBAC binding
         ↓
       原始 kubeconfig → Forbidden (请求被拒绝)
       后门 SA token  → cluster-admin 全权限 (仍能正常使用)

经验丰富的攻击者拿到一份泄露的 kubeconfig(cluster-admin 权限)后,第一件事可能不是立刻操作,而是先给自己埋一个独立的后门——即使原始 kubeconfig 被吊销,后门依然有效。kubeadm certs renew 和删除 ClusterRoleBinding 对已植入的后门无效,因为后门使用独立的身份凭证。

阅读更多

k8s KubeConfig泄露-黑客远程调用ApiServer创建特权容器获取Node节点权限应急排查

近2年的应急响应案例中,k8s的入侵案例逐渐增多。并且多次遇到客户云上内网被入侵后黑客窃取了KubeConfig文件,从公网远程调用ApiServer创建容器获取Node服务器权限植入后门的案例。

开发者/CI 系统的 kubeconfig 文件泄露到 Git / 日志 / 备份
        │
        ▼  黑客获取该文件
黑客在公网直接调用 apiserver(6443 端口)
        │
        ▼  权限确认为 cluster-admin
黑客创建一个特权 Pod,挂载宿主机根目录
        │
        ▼  kubectl exec 进容器
chroot / nsenter 拿到 Node 宿主机的 root shell
        │
        ▼
完全控制该 Node 宿主机

泄露途径非常多样:.kube/config 被 git add -A 带进仓库、CI 流水线打印了 KUBECONFIG 环境变量、开发者把 kubeconfig 存到共享网盘……一旦泄露,攻击者就能以持有人的身份操作集群,而集群本身不会有任何告警。

阅读更多

Git/SVN 应急响应排查实战手册

随着最近几年AI普及之后,供应链的攻击层出不穷,代码仓库被投毒的案例更是屡见不鲜。但是目前针对git/svn 还没有系统性的排查方案,所以这一块的应急排查内容还是空白。本文是我经历过多次代码投毒的真实案例后,写的实战排查手册。

阅读更多

内存取证-没有debuginfo时如何解决符号表的难题

任何曾经做过Linux内存取证的人都面临过这种场景:没有与内存镜像对应特定内核版本相匹配的调试符号,就寸步难行。各大云厂商(hyperscaler)在开源Linux内核 + 用户态组件的基础上,针对自家云基础设施进行深度定制和优化的Linux发行版(Linux Distribution)。这些发行版往往自带定制内核,而且还没有找到对应的debuginfo下载途径,面对这种场景会非常痛苦。

并且这些符号通常不会安装在生产系统上,必须从外部存储库获取,而当系统更新时,这些符号很快就会过时。如果你曾经尝试分析内存转储,却发现没有人发布该特定内核构建的符号,就会明白这种感觉。

阅读更多

OpenVPN 恶意DNS告警反查 VPN 客户端

【MSS高危告警】
--------------------------
【标题】:xxx发现DNS恶意请求
【客户名称】:xxxxxxxx
【云平台】:腾讯云
【客户账号】:xxxxxxxxx
【风险等级】:高危
【攻击IP】:
【告警时间】:2026-03-30 11:41:46
【事件类型】:恶意请求行为
【受影响资产】:10.59.240.14
【详情】:[公网IP:xxx.xx.xxx.x,机器:xxxxx,请求恶意域名:apifox.it.com,进程:,请求次数:1,首次请求时间:2026-03-30 11:41:46,最近请求时间:2026-03-30 11:41:46,Hash:xxxxxxxxx]

最近在处理MSS安全告警的时候遇到的问题:部署了 OpenVPN 的服务器上,HIDS 检测到了恶意域名的 DNS 请求,但因为请求是从 VPN 隧道内部发出的,告警里只能看到一个 OpenVPN 服务端自身的IP,没法直接定位到是哪台客户端机器、哪个用户触发的。

阅读更多

基于ESXI部署防溯源的攻击环境

最近这几年攻防对抗愈演愈烈,攻击队被溯源反制的案例也越来越多。我本身从事应急响应,想站在蓝队的视角,基于ESXI实现一套防溯源的攻击环境,本文的所有操作只需要在ESXI和Openwrt上配置。实现在隔离网段中创建的新机器无需任何配置,开机即用的效果。

阅读更多