# T1543.005 - Serviço de Container ## Técnica Pai Sub-técnica de [[t1543-create-or-modify-system-process|T1543 - Criar ou Modificar Processo do Sistema]], que cobre a manipulação de daemons, agentes e serviços para obter persistência ou escalada de privilégios. ## Descrição Adversários criam ou modificam ferramentas de gerenciamento de containers - como Docker, Podman e Kubernetes - que operam como daemons ou agentes em hosts individuais, para estabelecer persistência ou escalar privilégios em ambientes de infraestrutura moderna. Essa técnica explora a confiança implícita que orquestradores de containers depositam em seus agentes de nível de nó. Os principais vetores são: - **Docker/Podman com restart policy** - um container iniciado com `restart=always` reinicia automaticamente após falhas ou reinicializações do host, comportando-se como um serviço persistente sem precisar de registro no systemd - **Escalada via socket Docker** - um usuário com acesso ao socket `/var/run/docker.sock` (rootful Docker) pode montar o sistema de arquivos do host e obter acesso root efetivo - **Kubernetes DaemonSets** - recurso nativo que garante a execução de um pod em todos os nós do cluster, incluindo nós adicionados futuramente; adversários que comprometem o plano de controle podem criar DaemonSets maliciosos para persistência massiva - **nodeSelector / nodeName** - mecanismos do Kubernetes para direcionar pods a nós específicos, permitindo ao adversário concentrar payload em nós de maior valor (nós com acesso a segredos, nós de produção) - **Kubelet manipulation** - modificação do agente de nó do Kubernetes para alterar comportamento de agendamento ou exfiltrar credenciais No contexto latino-americano, a adoção acelerada de Kubernetes e containers em fintechs, e-commerces e bancos digitais do Brasil e México cria superfície de ataque crescente. Ambientes multi-tenant mal configurados - comuns em startups e empresas em fase de migração para cloud - frequentemente expõem o socket Docker ou têm RBAC do Kubernetes mal definido, tornando essa técnica particularmente eficaz em campanhas direcionadas ao setor financeiro regional. Containers também podem ser configurados para executar como [[t1543-002-systemd-service|Serviços Systemd]], combinando persistência em nível de SO com isolamento de container. Para implantação ativa de containers maliciosos em clusters, ver [[t1610-deploy-container|T1610 - Implantar Container]]. ## Attack Flow ```mermaid graph TB A([Acesso Inicial<br/>ao ambiente container]) --> B{Vetor de persistência} B --> C[Docker/Podman<br/>restart=always] B --> D[Acesso ao socket<br/>/var/run/docker.sock] B --> E[Kubernetes<br/>DaemonSet malicioso] B --> F[Modificação<br/>do kubelet] C --> G[Container reinicia<br/>automaticamente no boot] D --> H[Montagem do<br/>filesystem do host] H --> IEscalada de privilégios\nvia acesso root ao host] E --> J[Pod implantado em<br/>todos os nós do cluster] F --> K[Comportamento alterado<br/>no agente de nó] G --> L([Persistência estabelecida<br/>em nível de host]) I --> L J --> L K --> L L --> M[Execução continuada<br/>de payload malicioso] M --> NColeta de segredos\ne exfiltração de dados] ``` ## Como Funciona **Passo 1 - Obtenção de acesso ao runtime de containers** O adversário obtém acesso ao daemon Docker, socket Podman, ou ao plano de controle do Kubernetes - sejá por credenciais comprometidas, exploração de vulnerabilidade em API exposta, ou movimentação lateral a partir de um container já comprometido. Em muitos ambientes, o socket Docker é acessível a usuários do grupo `docker`, que efetivamente equivale a acesso root no host. **Passo 2 - Criação de container ou objeto Kubernetes persistente** Para Docker/Podman, o adversário executa um container com `--restart=always` ou `--restart=unless-stopped`, garantindo que ele sejá reiniciado pelo daemon independentemente de falhas ou reboots do host. Em Kubernetes, cria um DaemonSet via `kubectl apply` ou diretamente via API, específicando a imagem maliciosa e configurações de tolerância para nós com taints. A criação de um DaemonSet garante propagação automática a todos os nós existentes e futuros. **Passo 3 - Evasão e operação continuada** Containers persistentes se misturam ao tráfego legítimo de infraestrutura. Em ambientes com muitos microserviços, um DaemonSet adicional pode passar despercebido por semanas. O adversário pode configurar o container para executar ferramentas de reconhecimento interno, acessar secrets do Kubernetes montados automaticamente no pod, ou estabelecer túneis de saída aproveitando regras de rede permissivas entre pods. A política `restart=always` garante que mesmo após detecção e kill manual do container, ele sejá reiniciado pelo daemon. ## Detecção ```yaml title: Container Criado com Política de Reinício Persistente id: b7e3d2a1-9f5c-4b8e-a2d7-3c4f1e09b5d2 status: experimental description: > Detecta criação de containers Docker ou Podman com política de reinício que garante persistência entre reboots do host, indicando possível abuso de T1543.005. logsource: category: process_creation product: linux detection: selection_docker: Image|endswith: - '/docker' - '/podman' CommandLine|contains: - '--restart=always' - '--restart=unless-stopped' - 'restart: always' filter_legitimate: ParentImage|contains: - 'docker-compose' - 'systemd' condition: selection_docker and not filter_legitimate falsepositives: - Implantação legítima de serviços de infraestrutura via pipelines CI/CD - Administradores configurando containers de monitoramento level: medium tags: - attack.persistence - attack.t1543.005 ``` ## Mitigação | ID | Mitigação | Descrição | |---|-----------|-----------| | M1054 | [[m1054-software-configuration\|M1054 - Software Configuration]] | Configurar Docker com modo rootless sempre que possível. Restringir acesso ao socket `/var/run/docker.sock`. No Kubernetes, habilitar Pod Security Admission (PSA) com perfis `restricted` ou `baseline` para impedir escalada de privilégios via containers. | | M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Implementar RBAC granular no Kubernetes - princípio do menor privilégio para contas de serviço. Remover usuários desnecessários do grupo `docker`. Auditar periodicamente quem tem permissão para criar DaemonSets, Deployments e acessar o plano de controle. | | - | Monitoramento de API | Habilitar audit logs do Kubernetes (`--audit-log-path`) e monitorar criação de DaemonSets e alterações em recursos de nível de cluster por contas não esperadas. | ## Referências *Fonte: [MITRE ATT&CK - T1543.005](https://attack.mitre.org/techniques/T1543/005)*