用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/CyberStrikeus/CyberStrike --skill t1552-007-container-api命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
macOS post-exploitation for credential harvesting, DTrace monitoring, TCC bypass, and stealth operations via native tools
Windows userland post-exploitation for credential harvesting, monitoring, AMSI/ETW bypass, and stealth operations
Kubernetes post-exploitation for container escape, secret extraction, RBAC abuse, and cluster persistence
基于 SOC 职业分类
正在显示 SKILL.md
| name | T1552.007_container-api |
| description | Adversaries may gather credentials via APIs within a containers environment. |
| category | authentication |
| version | 18.1 |
| author | cyberstrike-official |
| tags | ["mitre-attack","enterprise","t1552.007","credential-access","containers","sub-technique"] |
| technique_id | T1552.007 |
| tactic | credential-access |
| all_tactics | ["credential-access"] |
| platforms | ["Containers"] |
| mitre_url | https://attack.mitre.org/techniques/T1552/007 |
| tech_stack | ["containers"] |
| cwe_ids | ["CWE-522"] |
| chains_with | ["T1552","T1552.001","T1552.002","T1552.003","T1552.004","T1552.005","T1552.006","T1552.008"] |
| prerequisites | ["T1552"] |
| severity_boost | {"T1552":"Chain with T1552 for deeper attack path","T1552.001":"Chain with T1552.001 for deeper attack path","T1552.002":"Chain with T1552.002 for deeper attack path"} |
Sub-technique of: T1552
Adversaries may gather credentials via APIs within a containers environment. APIs in these environments, such as the Docker API and Kubernetes APIs, allow a user to remotely manage their container resources and cluster components.
An adversary may access the Docker API to collect logs that contain credentials to cloud, container, and various other resources in the environment. An adversary with sufficient permissions, such as via a pod's service account, may also use the Kubernetes API to retrieve credentials from the Kubernetes API server. These credentials may include those needed for Docker API authentication or secrets from Kubernetes cluster components.
Platforms: Containers
The following tests are from Atomic Red Team and provide actionable ways to test this technique:
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services or provide further access to the cluster. More information about secrets.
This test will make a request to the Kubernetes api at the /api/v1/secrets endpoint requesting every secret stored within the cluster.
Supported Platforms: containers
kubectl get secrets --all-namespaces
Dependencies:
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services.
Supported Platforms: containers
kubectl get secrets -n #{namespace}
Dependencies:
If Atomic Red Team tests are not applicable, manually verify the technique by:
Identify Attack Surface: Determine if the target environment is susceptible to Container API by examining the target platforms (Containers).
Assess Existing Defenses: Review whether mitigations for T1552.007 are in place. If defenses are absent or misconfigured, this technique may be exploitable.
Execute Test: Use tools and methods described in the MITRE ATT&CK page and external references below.
Use the principle of least privilege for privileged accounts such as the service account in Kubernetes. For example, if a pod is not required to access the Kubernetes API, consider disabling the service account altogether.
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. 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. Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.
Enforce authentication and role-based access control on the container API to restrict users to the least privileges required. When using Kubernetes, avoid giving users wildcard permissions or adding users to the system:masters group, and use RoleBindings rather than ClusterRoleBindings to limit user privileges to specific namespaces.
| Finding | Severity | Impact |
|---|---|---|
| Container API technique applicable | High | Credential Access |
| CWE ID | Title |
|---|---|
| CWE-522 | Insufficiently Protected Credentials |