容器与资源发现是攻击者在云原生环境中识别可用计算资源、服务拓扑及集群配置的关键侦察技术，通常通过Kubernetes API调用、容器日志分析或管理仪表盘查询实现。防御方可通过集中化日志监控、API调用行为分析及服务账户权限管控等手段，检测异常资源枚举行为，例如非授权用户访问/apis/metrics.k8s.io/v1beta1接口或高频次查询节点信息。
为规避传统检测机制，攻击者发展出深度结合云原生特性的隐蔽探测技术，通过污染日志可信性、模拟合法API交互模式、利用容器网络隔离特性及动态身份切换等手法，将资源发现行为融入正常的集群运维流量中，形成"低特征、高动态"的新型侦察范式。
现有匿迹技术的共性在于充分利用云原生架构的复杂性与动态性重构攻击面。攻击者通过多维度身份伪装突破基于RBAC的检测体系，例如动态凭证轮换技术将固定身份威胁转化为流动身份威胁；通过协议仿冒规避网络层检测，如API请求伪装技术严格遵循OpenAPI规范构造合法请求；通过环境特性滥用实现行为隐藏，如容器内隐蔽探测技术利用服务网格的加密通信特性作为天然隐匿通道。此外，攻击者主动制造数据噪声（如日志污染）提升防御方的情报筛选成本，迫使安全团队在误报率与检出率之间进行权衡。
匿迹技术的演进使得传统基于静态规则匹配（如固定API调用频率阈值）或单一数据源分析（如仅监控审计日志）的防御手段逐渐失效。防御方需构建跨日志、网络流量、身份凭证多维度的关联分析体系，引入服务账户行为画像技术，并强化容器运行时微行为监控能力，方能有效应对新型隐蔽资源发现威胁。
| 效应类型 | 是否存在 |
|---|---|
| 特征伪装 | ✅ |
| 行为透明 | ❌ |
| 数据遮蔽 | ✅ |
| 时空释痕 | ✅ |
攻击者通过严格遵循云原生组件的标准通信协议（如Kubernetes API规范）和模拟合法管理行为（如服务健康检查），使资源发现请求在协议结构、加密特征及交互模式层面与正常运维流量无法区分。例如API请求伪装技术使用合规的User-Agent头和OAuth 2.0令牌格式，实现恶意流量的“协议合规化”伪装。
在容器内隐蔽探测技术中，攻击者利用服务网格的mTLS加密通道传输资源探测结果，使网络层检测设备无法解析载荷内容。同时，动态凭证轮换技术通过短期令牌机制确保敏感操作与凭证信息的即时失效，形成操作记录的数据遮蔽效应。
攻击者通过动态身份切换和低频次探测节奏，将集中式资源发现任务分散到长周期、多身份的攻击序列中。例如日志污染技术通过持续注入噪声日志，使得关键操作的时间戳特征被稀释在数天甚至数周的日志数据流中，破坏基于时序分析的检测模型。
| ID | Name | Description |
|---|---|---|
| S0601 | Hildegard |
Hildegard has used masscan to search for kubelets and the kubelet API for additional running containers.[1] |
| S0683 | Peirates |
Peirates can enumerate Kubernetes pods in a given namespace.[2] |
| G0139 | TeamTNT |
TeamTNT has checked for running containers with |
| ID | Mitigation | Description |
|---|---|---|
| M1035 | Limit Access to Resource Over Network |
Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API and Kubernetes API Server.[5][6] In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server.[7] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[8] |
| M1030 | Network Segmentation |
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls. |
| M1018 | User Account Management |
Enforce the principle of least privilege by limiting dashboard visibility to only the required users. When using Kubernetes, avoid giving users wildcard permissions or adding users to the |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0032 | Container | Container Enumeration |
Monitor logs for actions that could be taken to gather information about container infrastructure, including the use of discovery API calls by new or unexpected users. Monitor account activity logs to see actions performed and activity associated with the Kubernetes dashboard and other web applications. |
| DS0014 | Pod | Pod Enumeration |
Monitor logs for actions that could be taken to gather information about pods, including the use of discovery API calls by new or unexpected users. Monitor account activity logs to see actions performed and activity associated with the Kubernetes dashboard and other web applications. |