t1564-013-bind-mounts

# T1564.013 - Hide Artifacts: Bind Mounts > [!info] Identificação MITRE ATT&CK > **ID:** T1564.013 | **Tática:** Defense Evasion | **Subtécnica de:** [[t1564-hide-artifacts|T1564 - Hide Artifacts]] > **Plataformas:** Linux | **Versão MITRE:** 16.2 | **Referência:** [attack.mitre.org/techniques/T1564/013](https://attack.mitre.org/techniques/T1564/013) ## Descrição A subtécnica **T1564.013 - Bind Mounts** descreve o abuso de montagens vinculadas (bind mounts) do sistema de arquivos Linux para ocultar processos maliciosos, artefatos e atividades de ferramentas nativas de monitoramento. É uma técnica de evasão sofisticada que explora um mecanismo fundamental do kernel Linux para criar uma "cortina" sobre processos em execução. Um bind mount é um recurso legítimo do Linux que permite mapear um diretório ou arquivo de uma localização do sistema de arquivos para outra - funcionalmente similar a um link simbólico, mas operando no nível do VFS (Virtual Filesystem Switch) do kernel. Administradores de sistema usam bind mounts legitimamente para compartilhar diretórios entre ambientes chroot, expor caminhos dentro de containers Docker/LXC, e configurar ambientes de teste isolados. O abuso por adversários explora a interação do bind mount com o pseudo-sistema de arquivos `/proc`, que é a interface principal que utilitários como `ps`, `top`, `htop` e `lsof` usam para enumerar processos ativos. Ao sobrepor o diretório `/proc/[PID-malicioso]` com o conteúdo do diretório `/proc/[PID-benigno]`, o adversário faz o kernel apresentar metadados falsos para qualquer ferramenta que consulte aquele PID - incluindo ferramentas forenses e agentes EDR que dependem de leitura do `/proc`. **Técnica pai:** [[t1564-hide-artifacts|T1564 - Hide Artifacts]] ## Como Funciona ### Fundamentos do /proc no Linux O sistema de arquivos `/proc` é gerado dinâmicamente pelo kernel. Para cada processo com PID `N`, existe um diretório `/proc/N/` contendo: | Arquivo/Dir | Conteúdo | |---|---| | `/proc/N/exe` | Link simbólico para o executável do processo | | `/proc/N/cmdline` | Argumentos da linha de comando | | `/proc/N/maps` | Mapa de memória do processo | | `/proc/N/status` | Estado e informações do processo | | `/proc/N/net/` | Informações de rede do namespace | | `/proc/N/fd/` | File descriptors abertos | Quando `ps aux` ou `top` é executado, o kernel percorre `/proc/` e lê estes arquivos para construir a listagem de processos. Não há outro mecanismo padrão de enumeração de processos no espaço do usuário. ### Mecanismo do Ataque **Pré-requisitos:** - Acesso root (ou capacidade `CAP_SYS_ADMIN`) - necessário para executar `mount` - Conhecimento do PID do processo malicioso e de um PID benigno disponível **Execução do bind mount:** O adversário executa um bind mount que sobrepõe o diretório `/proc` do processo malicioso com o de um processo benigno (ex: um processo do sistema como `cron` ou `sshd`): ``` mount --bind /proc/[PID-benigno] /proc/[PID-malicioso] # ou equivalentemente: mount -o bind /proc/[PID-benigno] /proc/[PID-malicioso] ``` Após este comando, quando qualquer ferramenta de enumeração acessa `/proc/[PID-malicioso]/`, o kernel segue o bind mount e retorna o conteúdo de `/proc/[PID-benigno]/`. O processo malicioso continua executando normalmente, mas é invisível para ferramentas de espaço do usuário. ### Variantes da Técnica **Ocultação via diretório vazio:** Montar um diretório vazio sobre `/proc/[PID-malicioso]/` faz o diretório aparecer vazio para ferramentas de enumeração, sem revelar a existência de outro processo: ``` mkdir /tmp/.empty mount --bind /tmp/.empty /proc/[PID-malicioso] ``` **Ocultação de arquivos específicos:** A técnica também pode ser aplicada a arquivos individuais dentro do `/proc`, ex: substituir apenas o `/proc/[PID]/cmdline` para mascarar argumentos sem esconder o processo inteiro. **Combinação com namespaces:** Em ambientes containerizados, adversários podem combinar bind mounts com manipulação de namespaces de PID ([[t1611-escape-to-host|T1611]]) para criar processos que existem no namespace do host mas são invisíveis dentro do container e vice-versa. ## Attack Flow ```mermaid graph TB A["Acesso Inicial (Exploit / Credencial)"] --> B["Escalada de Privilégios para root / CAP_SYS_ADMIN"] B --> C["Implante Carregado (PID do processo malicioso)"] C --> D["Reconhecimento de Processos Benignos"] D --> E["Seleção de PID Alvo para Mascaramento"] E --> F["Execução do Bind Mount mount --bind /proc/benigno /proc/malicioso"] F --> G{"Tipo de Ocultação"} G -->|"Diretório /proc benigno"| H["Processo aparece como processo legítimo"] G -->|"Diretório vazio"| I["Processo desaparece completamente do /proc"] H --> J["ps / top / htop retornam dados falsos"] I --> J J --> K["EDR / Agentes de Monitoramento Não detectam o processo"] K --> L["Persistência e Operações Sem detecção"] style A fill:#2d3748,color:#e2e8f0 style F fill:#744210,color:#fefcbf style H fill:#742a2a,color:#fed7d7 style I fill:#742a2a,color:#fed7d7 style L fill:#22543d,color:#c6f6d5 ``` ## Exemplos de Uso ### Contexto em Operações de Red Team Embora T1564.013 sejá uma técnica relativamente recente na catalogação MITRE (adicionada em 2024), bind mounts abusivos têm sido observados em operações ofensivas avançadas desde pelo menos 2020. A técnica é especialmente relevante em: **Implantes em servidores Linux corporativos:** Grupos APT com foco em persistência de longo prazo em servidores web, bancos de dados e gateways VPN Linux empregam bind mounts para manter backdoors invisíveis durante semanas ou meses. Após comprometer um servidor com uma vulnerabilidade de aplicação web, o adversário escala privilégios ([[t1068-exploitation-for-privilege-escalation|T1068]]), instala um backdoor e usa bind mount para ocultá-lo antes de estabelecer [[t1053-scheduled-task-job|T1053]] para persistência. **Malware de Cryptomining:** Grupos de cryptomining como [[g0106-rocke|Rocke]] e afiliados do [[g0139-teamtnt|TeamTNT]] têm interesse direto em ocultar processos de mineração que consomem recursos visíveis (CPU/memória) - justamente o que `top` e `htop` monitoram. Bind mounts em combinação com rootkits LKM ([[t1547-006-kernel-modules-and-extensions|T1547.006]]) formam uma estratégia de evasão em camadas contra o monitoramento de recursos. **Ataques a Ambientes Kubernetes/Container:** Em ataques de escape de container ([[t1611-escape-to-host|T1611]]), após obter acesso ao host, adversários usam bind mounts para ocultar processos maliciosos que operam no namespace do host enquanto ferramentas de monitoramento de container inspecionam apenas namespaces de container. ### Grupos com Capacidade Relacionada Embora não hajá atribuição pública específica a T1564.013 no momento desta análise, grupos com histórico de técnicas avançadas de evasão em Linux e capacidade técnica para exploração de bind mounts incluem: - [[g0007-apt28|APT28 (Fancy Bear)]] - Reconhecido uso de rootkits e evasão avançada em servidores Linux - [[g0032-lazarus-group|Lazarus Group]] - Implantes Linux multi-plataforma com técnicas de ocultação sofisticadas - [[g1045-salt-typhoon|Salt Typhoon]] - Persistência avançada em infraestrutura de telecomúnicações Linux ## Detecção > [!warning] Dificuldade de Detecção > Bind mounts são **invisíveis para ferramentas que operam via /proc** - o mesmo mecanismo que a técnica compromete. A detecção requer abordagens alternativas ao /proc ou monitoramento em nível de kernel. ### Regra Sigma - Execução de mount com --bind em Contexto Suspeito ```yaml title: Bind Mount Suspeito sobre Diretório /proc id: c3d4e5f6-a7b8-9012-cdef-345678901234 status: experimental description: > Detecta execução do comando mount com flag --bind ou -o bind tendo /proc como destino, indicando possível ocultação de processo (T1564.013). references: - https://attack.mitre.org/techniques/T1564/013 author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1564.013 logsource: category: process_creation product: linux detection: selection_bind: Image|endswith: '/mount' CommandLine|contains: - '--bind' - '-o bind' - '-B ' selection_proc_target: CommandLine|contains: '/proc/' condition: selection_bind and selection_proc_target falsepositives: - Configuração legítima de containers Docker/LXC em ambientes de CI/CD - Administradores configurando chroot com /proc compartilhado level: high fields: - CommandLine - User - ParentImage - ParentCommandLine ``` ### Regra Sigma - Discrepância entre /proc e Chamadas de Sistema ```yaml title: Processo com Bind Mount Ativo sobre /proc detectado via audit id: d4e5f6a7-b8c9-0123-defa-456789012345 status: experimental description: > Detecta chamadas de sistema mount(2) com MS_BIND flag sobre caminhos /proc, via auditd syscall monitoring. Mais confiável que monitoramento de processo. references: - https://attack.mitre.org/techniques/T1564/013 author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1564.013 logsource: product: linux service: auditd detection: selection: type: 'SYSCALL' syscall: 'mount' selection_path: type: 'PATH' name|startswith: '/proc/' condition: selection and selection_path falsepositives: - Sistemas com containers em produção (alto volume de falsos positivos esperado) level: high ``` ### Métodos de Detecção Alternativos | Método | Como Implementar | Eficácia | |---|---|---| | **Leitura direta de /proc/mounts** | Monitorar `/proc/mounts` ou `/proc/self/mountinfo` para entradas bind sobre `/proc/[N]` | Alta | | **Comparação de /proc vs netlink** | Enumerar processos via Netlink (NLMSG_DONE) e comparar com /proc - discrepâncias indicam ocultação | Alta | | **eBPF / kprobes** | Monitorar syscall `mount(2)` com flag `MS_BIND` via eBPF sem depender de /proc | Muito Alta | | **Auditd syscall rules** | Regra `-a always,exit -F arch=b64 -S mount` no auditd | Alta | | **Leitura de /proc/[N]/mountinfo** | Verificar se cada processo tem bind mounts ativos no seu próprio /proc | Média | ## Mitigação > [!note] Limitações de Mitigação > O MITRE ATT&CK não cataloga mitigações específicas para T1564.013. A prevenção primária é limitar acesso root e a capacidade `CAP_SYS_ADMIN`. | Controle | Descrição | Eficácia | |---|---|---| | **Controle de Capacidades Linux** | Remover `CAP_SYS_ADMIN` de processos que não necessitam; usar capabilities mínimas via `setcap` | Alta | | **Seccomp / AppArmor** | Perfis Seccomp que bloqueiam a syscall `mount(2)` para processos não-privilegiados | Alta | | **Monitoramento de Integridade via eBPF** | Ferramentas como Falco, Tetragon ou Cilium Tetragon para detecção em nível de kernel | Alta | | **Imutabilidade de Sistema de Arquivos** | Sistemas operacionais imutáveis (Flatcar, CoreOS) que limitam operações de mount em runtime | Média-Alta | | **Auditoria Contínua de Mounts** | Scripts ou agentes que comparam `/proc/mounts` com estado esperado periodicamente | Média | | **Princípio de Menor Privilégio** | Minimizar processos rodando como root; usar sudo com logging para operações de mount | Alta | ## Contexto Brasil/LATAM A técnica T1564.013 tem relevância crescente no contexto regional em virtude da expansão da infraestrutura de servidores Linux em setores críticos: ### Setores em Risco **Setor Financeiro:** Bancos digitais e fintechs brasileiras operam extensas infraestruturas Linux (backends de aplicação, APIs Pix, gateways de pagamento). A sophisticação de grupos de crime financeiro que operam na região - incluindo grupos que desenvolveram trojans bancários multiplataforma - aumenta o risco de uso de técnicas como bind mounts para persistência em servidores de alta criticidade. **Telecomúnicações:** A operação Salt Typhoon, documentada em 2024, comprometeu infraestrutura de telecomúnicações globalmente, com potencial impacto em operadoras LATAM. Técnicas de evasão avançada em Linux são parte integral do arsenal deste grupo. Operadoras brasileiras reguladas pela Anatel têm obrigação de notificar o CERT.br em incidentes deste tipo. **Cloud e DevOps:** A adoção acelerada de Kubernetes e containers em empresas brasileiras cria superfícies de ataque onde bind mounts são usados legitimamente - dificultando a detecção de uso malicioso e aumentando a urgência de monitoramento via eBPF (ex: Falco com regras específicas). ### Dificuldades Operacionais Equipes de SOC no Brasil enfrentam desafio específico: a maioria das ferramentas de SIEM implantadas ainda coleta eventos via agente syslog ou Filebeat - que dependem do próprio sistema de arquivos e do /proc. Soluções baseadas em eBPF (Falco, Tetragon) ainda têm baixa penetração no mercado brasileiro, tornando esta técnica particularmente difícil de detectar sem investimento dedicado em modernização de stack de detecção. ## Referências - [MITRE ATT&CK - T1564.013](https://attack.mitre.org/techniques/T1564/013) - [Linux man page - mount(8)](https://man7.org/linux/man-pages/man8/mount.8.html) - [Falco Rules para Bind Mounts](https://falco.org/docs/rules/) - [Tetragon - eBPF-based Security Observability](https://tetragon.io/) - [Linux /proc filesystem documentation](https://www.kernel.org/doc/html/latest/filesystems/proc.html) **Técnicas Relacionadas:** [[t1564-hide-artifacts|T1564]], [[t1014-rootkit|T1014]], [[t1068-exploitation-for-privilege-escalation|T1068]], [[t1611-escape-to-host|T1611]], [[t1547-006-kernel-modules-and-extensions|T1547.006]], [[t1053-scheduled-task-job|T1053]], [[t1070-002-clear-linux-or-mac-system-logs|T1070.002]] **Threat Actors com Capacidade Relacionada:** [[g0007-apt28|APT28]], [[g0032-lazarus-group|Lazarus Group]], [[g1045-salt-typhoon|Salt Typhoon]], [[g0106-rocke|Rocke]], [[g0139-teamtnt|TeamTNT]] --- *Fonte: [MITRE ATT&CK - T1564.013](https://attack.mitre.org/techniques/T1564/013)*