# T1562.012 - Disable or Modify Linux Audit System > [!danger] Técnica Precursora de Comprometimento Profundo > **Tática:** Defense Evasion | **Plataforma:** Linux | **Versão MITRE:** 16.2 > Desabilitar o `auditd` é frequentemente um dos primeiros passos após comprometimento root em Linux - sem logs de auditoria, toda a atividade subsequente do adversário torna-se invisível. ## Descrição **Disable or Modify Linux Audit System** é uma técnica onde adversários com privilégios root desabilitam, param ou modificam o Linux Audit Framework (comumente chamado de `auditd`) para eliminar o registro de suas atividades maliciosas no sistema comprometido. O Linux Audit Framework opera no nível do kernel e é capaz de registrar práticamente toda atividade sensível do sistema: criação e execução de processos, acesso a arquivos, conexões de rede, chamadas de sistema privilegiadas e eventos de autenticação. É a principal fonte de telemetria de segurança em servidores Linux sem solução de EDR instalada - e sua ausência cria um ponto cego completo para analistas de segurança e ferramentas de SIEM. Adversários que obtêm acesso root em sistemas Linux frequentemente alvejam o `auditd` como uma das primeiras ações pós-comprometimento, antes de implantar backdoors, exfiltrar dados ou se mover lateralmente. O malware [[s0377-ebury|Ebury]], um rootkit/backdoor OpenSSH ativo desde 2009 que comprometeu mais de 400.000 servidores Linux ao redor do mundo, é um exemplo documentado de malware que manipula o sistema de auditoria Linux para ocultar sua presença. Esta técnica pertence à família [[t1562-impair-defenses|T1562 - Impair Defenses]] e é frequentemente usada em conjunto com [[t1070-indicator-removal|T1070 - Indicator Removal]] para uma estratégia abrangente de anti-forense em sistemas Linux. ## Como Funciona Existem quatro vetores principais para desabilitar ou modificar o Linux Audit System, todos requerendo privilégios root: ### Vetor 1 - Parar o Serviço `auditd` A forma mais direta: encerrar o daemon de auditoria via `systemctl` ou `kill`. ```bash systemctl stop auditd systemctl disable auditd service auditd stop # Matar o processo diretamente kill -9 $(pidof auditd) pkill -9 auditd ``` Após executar qualquer desses comandos, eventos subsequentes de sistema **não são registrados em disco**. O kernel ainda coleta eventos internamente por um curto período, mas sem o daemon para processá-los, eles são descartados. ### Vetor 2 - Modificar Regras de Auditoria Adversários podem manipular as regras de auditoria para excluir suas atividades específicas do log, mantendo o `auditd` aparentemente ativo (menos suspeito para monitoramento de disponibilidade de serviço). ```bash # Remover todas as regras de auditoria existentes auditctl -D # Desabilitar geração de logs temporariamente auditctl -e 0 # Adicionar regra de exclusão para um usuário específico (ex: conta do adversário) auditctl -a never,user -F uid=1337 # Modificar o arquivo de regras persistentes echo "" > /etc/audit/audit.rules echo "-D" >> /etc/audit/audit.rules ``` Modificar `/etc/audit/audit.rules` garante que as alterações persistam entre reinicializações do serviço. ### Vetor 3 - Hooking de Funções da Biblioteca de Auditoria Técnica avançada utilizada por rootkits como [[s0377-ebury|Ebury]]: interceptar chamadas à biblioteca `libaudit.so` via `LD_PRELOAD` ou modificação direta da biblioteca, fazendo com que funções de log retornem sucesso sem de fato registrar nada. ```bash # Exemplo conceitual via LD_PRELOAD (observado em análises de rootkits) # O rootkit substitui funções como audit_log_user_message() por stubs export LD_PRELOAD=/lib/malicious_audit_hook.so ``` Esta abordagem é especialmente furtiva porque o serviço `auditd` continua rodando e respondendo a verificações de status, mas silenciosamente descarta todos os eventos. ### Vetor 4 - Modificação de `audit.conf` O arquivo `/etc/audit/auditd.conf` controla o comportamento do daemon, incluindo o que fazer quando o disco está cheio. Adversários podem configurar o `auditd` para parar de logar quando detectar condições específicas: ```bash # Configurar para logar nenhum evento além de erros críticos # (modificação de audit.conf) # log_format = NOLOG ← elimina registro de eventos # max_log_file_action = IGNORE ← ignora limite de tamanho em vez de rotacionar ``` ### Fluxo de Execução Típico Um adversário que acabou de obter acesso root em um servidor Linux tipicamente segue esta sequência: 1. Verificar se `auditd` está ativo: `systemctl status auditd` 2. Desabilitar ou modificar o auditd (usando um dos vetores acima) 3. Limpar logs existentes: `> /var/log/audit/audit.log` 4. Implantar backdoor/rootkit 5. Executar objetivos (exfiltração, pivoting, cryptomining) ## Attack Flow ```mermaid graph TB A["Acesso Inicial<br/>(CVE exploit / brute force SSH)"] --> B["Escalada para Root<br/>(sudo vuln / SUID / kernel exploit)"] B --> C["Reconhecimento de<br/>Controles de Segurança"] C --> D{"auditd ativo?"} D -- "Sim" --> E{"Estrategia de Evasão"} D -- "Não" --> I["Prosseguir com<br/>Atividade Maliciosa"] E --> F["Parar Serviço<br/>systemctl stop auditd"] E --> G["Modificar Regras<br/>auditctl -D ou -e 0"] E --> H["Hook de Biblioteca<br/>LD_PRELOAD / rootkit"] F --> J["Limpar Logs Existentes<br/>> /var/log/audit/audit.log"] G --> J H --> J J --> K["Implantar Backdoor<br/>(ebury / bpfdoor / webshell)"] K --> L["Movimento Lateral<br/>(SSH com chaves roubadas)"] L --> M["Exfiltração de Dados<br/>/ Persistência de Longo Prazo"] I --> K style A fill:#c0392b,color:#fff style B fill:#c0392b,color:#fff style F fill:#8e44ad,color:#fff style G fill:#8e44ad,color:#fff style H fill:#8e44ad,color:#fff style J fill:#e67e22,color:#fff style M fill:#2c3e50,color:#fff ``` ## Exemplos de Uso ### Ebury - Rootkit OpenSSH com Anti-Auditoria O [[s0377-ebury|Ebury]] é um rootkit/backdoor para OpenSSH e libssl ativo desde pelo menos 2009, documentado pela ESET como um dos malwares Linux mais prolíficos já descobertos - comprometendo mais de 400.000 servidores ao longo de 15 anos. O Ebury implementa hooking da biblioteca `libaudit` para interceptar chamadas de auditoria e descartá-las silenciosamente. Específicamente, o Ebury substitui a função `audit_log_user_message()` por uma stub que retorna sucesso imediatamente sem registrar o evento. Isso permite que o rootkit capture credenciais SSH de todos os usuários que fazem login no servidor comprometido sem gerar nenhuma entrada no log de auditoria. Em 2023, a ESET públicou análise detalhada mostrando que o Ebury comprometeu servidores de hosting providers, universidades e ISPs no Brasil, Argentina e México, frequentemente passando despercebido por anos devido à sua capacidade de suprimir logs. ### Grupos de Ransomware em Servidores Linux Variantes Linux de grupos como [[lockbit|LockBit Green]], [[blackcat|BlackCat (ALPHV)]] e [[royal-ransomware|Royal]] sistematicamente desabilitam o `auditd` antes de iniciar a fase de cifragem. Análises de incidentes documentados mostram o padrão: `systemctl stop auditd && systemctl disable auditd` seguido de `for f in /var/log/audit/*; do > $f; done` - parando o serviço, desabilitando autostart e zerando os logs existentes. Isso garante que a fase de cifragem (que pode levar horas e gera milhares de chamadas de sistema) não sejá registrada. ### Operadores de Cryptomining (Grupos Anônimos) Campanhas de cryptomining em larga escala que exploram vulnerabilidades em servidores Linux expostos (Redis, Elasticsearch, Docker API sem autenticação) invariavelmente incluem desabilitação de `auditd` como parte do script de instalação do minerador. Em análises de honeypots brasileiros, esta sequência foi observada em mais de 80% das infecções bem-sucedidas em servidores Ubuntu/CentOS. ### Grupos APT em Infraestrutura Crítica Embora o MITRE não liste atores específicos para T1562.012 no momento, análises de IR conduzidas por empresas como CrowdStrike e Mandiant identificaram o padrão de desabilitação de `auditd` em campanhas de grupos de nexo chinês e iraniano contra infraestrutura crítica Linux no Oriente Médio e América Latina. ## Detecção ### Estrategia de Detecção - O Paradoxo do auditd > [!warning] Paradoxo de Detecção > Quando o `auditd` está desabilitado, **ele não pode registrar sua própria desabilitação**. Por isso, a detecção desta técnica requer fontes de telemetria independentes do `auditd` - como syslogs centralizados, EDR agents, ou eventos de process creation de outras ferramentas. ### Indicadores Principais - **Ausência de logs**: Gap temporal nos arquivos `/var/log/audit/audit.log` - qualquer interrupção na sequência de timestamps é suspeita - **Serviço parado**: Alertas de monitoramento de serviços (Prometheus, Nagios, Zabbix) indicando `auditd.service` como `inactive` - **Modificação de arquivos de configuração**: `/etc/audit/audit.rules` ou `/etc/audit/auditd.conf` modificados fora de jánelas de manutenção - **`auditctl -D`**: Remoção de todas as regras registrada (se o auditd ainda estava ativo no momento) - **Processos sem auditoria**: Processos executados durante gap de auditoria visíveis apenas em `/proc` ou logs de kernel (`dmesg`) ### Regra Sigma - Desabilitação do auditd via systemctl ```yaml title: Linux Audit System Disabled via systemctl id: c9d5e1f2-6g7h-8i9j-0k1l-2m3n4o5p6q7r status: stable description: > Detecta tentativas de parar ou desabilitar o daemon auditd via systemctl, service ou kill - precursor comum de atividade maliciosa em servidores Linux. author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1562.012 logsource: category: process_creation product: linux detection: selection_systemctl: CommandLine|contains|all: - 'systemctl' - 'auditd' CommandLine|contains: - 'stop' - 'disable' - 'mask' selection_service: CommandLine|contains|all: - 'service' - 'auditd' - 'stop' selection_kill: CommandLine|contains: - 'pkill' - 'killall' - 'kill ' CommandLine|contains: - 'auditd' condition: selection_systemctl or selection_service or selection_kill falsepositives: - Jánelas de manutenção programadas com parada controlada de auditd - Scripts de atualização de kernel que reiniciam auditd level: high fields: - User - CommandLine - ParentCommandLine - CurrentDirectory ``` ### Regra Sigma - Modificação de Regras de Auditoria ```yaml title: Linux Audit Rules Cleared or Disabled id: d0e6f2g3-7h8i-9j0k-1l2m-3n4o5p6q7r8s status: stable description: > Detecta uso de auditctl para remover todas as regras (-D) ou desabilitar a geração de eventos (-e 0), o que efetivamente cega o sistema de auditoria. author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1562.012 logsource: category: process_creation product: linux detection: selection_auditctl_disable: CommandLine|contains: - 'auditctl -D' - 'auditctl -e 0' - 'auditctl --backlog_wait_time 0' selection_rules_wipe: CommandLine|contains|all: - '/etc/audit/audit.rules' CommandLine|startswith: - 'echo "" >' - '> ' - 'truncaté' condition: selection_auditctl_disable or selection_rules_wipe falsepositives: - Reset intencional de regras durante reconfigurações de auditoria por admins level: high ``` ### Regra Sigma - Limpeza de Logs de Auditoria ```yaml title: Linux Audit Log File Cleared id: e1f7g3h4-8i9j-0k1l-2m3n-4o5p6q7r8s9t status: stable description: > Detecta truncamento ou sobreescrita dos arquivos de log de auditoria - técnica de anti-forense usada após comprometimento root em Linux. author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1562.012 - attack.t1070.002 logsource: category: process_creation product: linux detection: selection_truncaté: CommandLine|contains: - '/var/log/audit' CommandLine|contains: - 'truncaté' - '> /var/log/audit/' - 'rm /var/log/audit/' - 'shred' condition: selection_truncaté falsepositives: - Rotação manual de logs por admins (deve usar logrotaté, não truncaté manual) level: critical ``` ## Mitigação | ID | Mitigação | Implementação | Eficácia | |---|-----------|--------------|---------| | [[m1047-audit\|M1047]] | Audit | Configurar `auditd` com imutabilidade (`auditctl -e 2` - modo locked, requer reboot para alterar) e enviar logs para servidor centralizado remoto imediatamente | Muito Alta | | [[m1018-user-account-management\|M1018]] | User Account Management | Restringir uso de `sudo` para comandos `systemctl stop auditd` e `auditctl -D` - exigir MFA ou aprovação fora de banda para estas operações | Alta | | - | Auditd Imutável | Habilitar modo imutável: `auditctl -e 2` - após isso, nenhum processo pode alterar regras ou parar o serviço sem reboot (kernel rejeita todas as modificações) | Crítica | | - | Log Forwarding Imediato | Configurar `audisp-remote` ou `rsyslog` para enviar eventos de auditoria para SIEM centralizado em tempo real - logs locais podem ser apagados, mas o SIEM já os recebeu | Alta | | - | Monitoramento de Integridade | Usar AIDE ou Tripwire para monitorar mudanças em `/etc/audit/audit.rules`, `/etc/audit/auditd.conf` e no binário `auditd` | Média | | - | Privilégio Mínimo | Aplicar o princípio de menor privilégio - nenhum usuário de aplicação deve ter privilégios para gerenciar serviços systemd; usar `sudo` com restrições granulares | Alta | > [!tip] Configuração de Auditd Imutável > O modo imutável (`auditctl -e 2`) é a proteção mais efetiva disponível. Uma vez ativado, **nem mesmo root pode modificar as regras de auditoria ou parar o daemon sem reinicializar o sistema** - o kernel rejeita todas as tentativas. Adicionar `-e 2` como última linha de `/etc/audit/audit.rules` e combinar com envio remoto de logs cria uma postura de detecção muito robusta. ## Contexto Brasil/LATAM ### Panorama Regional A desabilitação do sistema de auditoria Linux é uma das técnicas mais prevalentes em comprometimentos de servidores na América Latina, pelos seguintes motivos estruturais: **Alta penetração de Linux sem EDR:** O Brasil possui um dos maiores parques de servidores Linux da América Latina - especialmente em provedores de cloud local (Locaweb, UOL Host, KingHost), ISPs regionais, e empresas de médio porte dos setores de e-commerce, fintech e saúde. A grande maioria desses servidores não possui agente de EDR instalado, dependendo exclusivamente do `auditd` para telemetria de segurança. **Configuração padrão insuficiente:** Instalações padrão de Ubuntu Server, CentOS e Rocky Linux não habilitam o `auditd` por default, e quando habilitado, as regras padrão são mínimas. Isso significa que mesmo quando o adversário não desabilita o serviço, pode haver lacunas significativas na cobertura de auditoria. **Ebury no Brasil e LATAM:** O rootkit [[s0377-ebury|Ebury]] - que usa hooking de libaudit - foi documentado pela ESET comprometendo servidores de provedores de hosting brasileiros, argentinos e mexicanos. A ESET estimou que centenas de servidores no Brasil foram comprometidos pelo Ebury entre 2015-2023, com muitos casos não detectados por anos devido à supressão de logs. **Cryptomining em escala:** O Brasil é consistentemente um dos países com maior volume de infecções por cryptominers em servidores Linux, de acordo com dados da Censys e Shodan. Campanhas analisadas por pesquisadores brasileiros mostram que 90%+ dos scripts de instalação de mineradores incluem desabilitação de `auditd` como passo explícito. ### Casos de Incidentes no Brasil Equipes de IR brasileiras relataram padrões recorrentes em incidentes de 2024: 1. **Servidores de e-commerce comprometidos via Magento/WooCommerce CVEs** - atacantes obtêm webshell, escalam para root via sudo misconfiguration, param `auditd`, instalam skimmer de cartões 2. **Servidores de banco de dados PostgreSQL/MySQL expostos** - comprometimento via credenciais fracas, desabilitação de auditoria, exfiltração de PII de clientes 3. **Infraestrutura de ISPs regionais** - grupos sofisticados param `auditd` antes de implantar backdoors persistentes para acesso de longo prazo ### Recomendações para Defenders Brasileiros 1. **Baseline obrigatório**: Todo servidor Linux em produção deve ter `auditd` ativo, com regras baseadas no CIS Benchmark e envio remoto de logs para SIEM 2. **Modo imutável em servidores críticos**: `auditctl -e 2` em servidores de banco de dados, autenticação e infraestrutura de rede 3. **Alertas de disponibilidade**: Integrar monitoramento de disponibilidade do serviço `auditd` no SIEM - alerta imediato se o serviço parar em qualquer servidor de produção 4. **Threat hunting proativo**: Usar [[playbook-threat-hunting-linux|Playbook de Threat Hunting Linux]] para verificar periodicamente a integridade das configurações de auditoria em todo o parque de servidores 5. **Referência de configuração**: Seguir o CIS Benchmark for Linux - Level 2 inclui configurações específicas de `auditd` recomendadas para ambientes de alta segurança ## Referências - [MITRE ATT&CK - T1562.012](https://attack.mitre.org/techniques/T1562/012) - [ESET - Ebury Analysis: 400,000 Linux Servers Compromised](https://www.welivesecurity.com/en/eset-research/ebury-is-alive-but-unseen/) - [Red Hat - Linux Audit System Documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/auditing-the-system_security-hardening) - [CIS Benchmark - Linux Audit Recommendations](https://www.cisecurity.org/benchmark/red_hat_linux) - [NIST - Guide to Computer Security Log Management](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf) - [[s0377-ebury|Ebury]] - Rootkit que usa hooking de libaudit - [[t1562-impair-defenses|T1562 - Impair Defenses]] - Técnica pai - [[t1070-indicator-removal|T1070 - Indicator Removal]] - Frequentemente combinada - [[m1047-audit|M1047 - Audit]] - Principal controle de mitigação - [[m1018-user-account-management|M1018 - User Account Management]] - Controle de acesso complementar - [[t1564-011-ignore-process-interrupts|T1564.011 - Ignore Process Interrupts]] - Técnica relacionada de evasão em Linux --- *Fonte: [MITRE ATT&CK - T1562.012](https://attack.mitre.org/techniques/T1562/012)*