# T1098.004 - Chaves SSH Autorizadas ## Técnica Pai Esta é uma sub-técnica de [[t1098-account-manipulation|T1098 - Manipulação de Conta]]. A inserção de chaves SSH não autorizadas no arquivo `authorized_keys` é uma das técnicas de persistência mais silenciosas e eficazes em ambientes Linux, macOS, nuvem e dispositivos de rede. Ao contrário de backdoors tradicionais, chaves SSH abusivas não requerem processos em execução permanente, não criam escutas de rede adicionais e aproveitam mecanismos de autenticação nativos e confiáveis do sistema operacional. ## Descrição O protocolo SSH utiliza criptografia de chave pública/privada como método de autenticação preferêncial em servidores Linux, macOS, hypervisors ESXi e dispositivos de rede. O arquivo `~/.ssh/authorized_keys` de cada usuário contém as chaves públicas cujos detentores da chave privada correspondente têm autorização para autenticar-se sem senha. Adversários que obtêm acesso suficiente ao sistema alvo podem inserir sua própria chave pública nesse arquivo, garantindo acesso SSH persistente mesmo após a troca de senhas da conta comprometida. O ataque é particularmente eficaz porque: (1) não requer instalação de software adicional; (2) aproveita um protocolo de rede legítimo e amplamente permitido nos firewalls corporativos; (3) o arquivo `authorized_keys` raramente é monitorado por soluções de segurança; (4) o acesso via chave SSH não deixa rastros de senha em logs de autenticação, dificultando a correlação forense. Em ambientes de nuvem (AWS, GCP, Azure), a técnica ganha dimensão adicional: adversários com acesso à API do provedor podem modificar o `authorized_keys` de instâncias virtuais remotamente, sem necessidade de acesso direto ao sistema. No Google Cloud, o comando `gcloud compute instances add-metadata` pode ser abusado para injetar chaves SSH. Na Azure, uma requisição PATCH à API REST de VMs permite o mesmo. Em ambientes ESXi, o arquivo equivalente fica em `/etc/ssh/keys-<username>/authorized_keys`. Em dispositivos de rede Cisco/Juniper, chaves SSH podem ser adicionadas via [[t1059-008-network-device-cli|CLI de Dispositivo de Rede]] com o comando `ip ssh pubkey-chain`. **Contexto Brasil/LATAM:** Esta técnica é amplamente documentada em campanhas contra infraestrutura em nuvem na América Latina. O grupo [[g0139-teamtnt|TeamTNT]], especializado em cryptojacking de ambientes cloud e Kubernetes, utiliza injeção de chaves SSH como mecanismo de persistência padrão após o comprometimento inicial de instâncias EC2 e contêineres expostos. No Brasil, provedores de cloud e empresas com infraestrutura Linux exposta à internet são alvos frequentes. O grupo [[g1006-earth-lusca|Earth Lusca]] e o [[g1045-salt-typhoon|Salt Typhoon]], ambos de origem chinesa, também documentam uso desta técnica em campanhas de espionagem que atingem telecomúnicações e governo na região. ## Attack Flow ```mermaid graph TB A[Acesso Inicial<br/>Exploit / Credencial Comprometida / API Cloud] --> B[Reconhecimento de Usuários<br/>cat /etc/passwd - identificar contas SSH-enabled] B --> C[Geração de Par de Chaves<br/>ssh-keygen no host do adversário] C --> D[T1098.004 - INJEÇÃO DE CHAVE SSH<br/>echo pub_key >> ~/.ssh/authorized_keys] D --> E[Persistência Estabelecida<br/>Acesso SSH sem senha com chave própria] E --> F1[Movimentação Lateral<br/>SSH para outros hosts usando a mesma chave] E --> F2[Escalada de Privilégio<br/>Chave adicionada a conta root ou privilegiada] F1 --> G[Objetivo Final<br/>Exfiltração / Cryptojacking / Ransomware] F2 --> G ``` ## Como Funciona 1. **Preparação** - O adversário obtém acesso ao sistema alvo (via shell remoto, exploit, credencial comprometida ou API cloud) e gera um par de chaves SSH em seu próprio ambiente. A chave pública gerada será inserida no alvo; a chave privada permanece sob controle do adversário e é usada para autenticação futura. 2. **Execução** - A chave pública é adicionada ao arquivo `authorized_keys` do usuário alvo - frequentemente `root` ou um usuário de serviço com privilégios elevados. Dependendo do ambiente, isso pode ser feito via redirecionamento de shell, script automatizado, ou API do provedor de nuvem. O adversário também pode modificar o `sshd_config` para habilitar `PubkeyAuthentication yes` e `PermitRootLogin yes` caso não estejam habilitados, maximizando o acesso. 3. **Pós-execução** - O adversário passa a autenticar-se via SSH usando sua chave privada, sem necessidade de senha. O acesso persiste mesmo após troca de credenciais da conta, reinstalação de aplicações, ou rotação de segredos que não incluam auditoria das chaves SSH. Em ambientes com múltiplos hosts e chaves SSH compartilhadas, o adversário pode movimentar-se lateralmente usando a mesma chave em outros sistemas. **Exemplo - verificação de chaves autorizadas (auditoria defensiva):** ```bash # Auditar todas as chaves SSH autorizadas no sistema (uso defensivo) for user in $(cut -f1 -d: /etc/passwd); do home=$(eval echo ~"$user") authkeys="$home/.ssh/authorized_keys" if [ -f "$authkeys" ]; then echo "=== $user ===" cat "$authkeys" fi done # Verificar data de modificação do arquivo (detectar adições recentes) find /home /root -name "authorized_keys" -newer /etc/passwd -ls 2>/dev/null ``` ## Detecção **Fontes de dados:** Logs de autenticação SSH (`/var/log/auth.log`, `/var/log/secure`); Monitoramento de integridade de arquivo (FIM) em `~/.ssh/authorized_keys`; Logs de API do provedor de nuvem (CloudTrail, GCP Audit, Azure Monitor); Auditoria de processos para comandos `ssh-keygen`, `echo` com redirecionamento para `.ssh/`; Alertas de EDR para escrita em arquivos `authorized_keys`. ```yaml title: Modificação Suspeita de Arquivo SSH Authorized Keys id: c91f4b72-3e8a-4c7d-d047-2b4f9c1a6e89 status: experimental logsource: category: file_event product: linux detection: selection: TargetFilename|endswith: - '/.ssh/authorized_keys' - '/authorized_keys' TargetFilename|contains: - '/root/' - '/home/' - '/etc/ssh/keys-' filter_admin_tools: Image|endswith: - '/sshd' - '/ssh-keygen' - '/ansible' - '/puppet' condition: selection and not filter_admin_tools falsepositives: - Automação legítima de provisionamento (Ansible, Terraform, Chef) - Administradores adicionando chaves pessoais via procedimento documentado - Ferramentas de gerenciamento de identidade (Vault, CyberArk) rotacionando chaves level: high tags: - attack.persistence - attack.privilege-escalation - attack.t1098.004 ``` ## Mitigação | Mitigação | Recomendação Prática | |-----------|---------------------| | [[m1018-user-account-management\|M1018 - User Account Management]] | Implementar processo formal de aprovação para adição de chaves SSH; auditar trimestralmente todos os `authorized_keys` em servidores de produção; remover chaves de ex-funcionários e contas de serviço obsoletas | | [[m1022-restrict-file-and-directory-permissions\|M1022 - Restrict File and Directory Permissions]] | Configurar permissões estritas: `chmod 700 ~/.ssh` e `chmod 600 ~/.ssh/authorized_keys`; o arquivo não deve ser gravável por grupo ou outros usuários; monitorar qualquer alteração de permissão via FIM | | [[m1042-disable-or-remove-feature-or-program\|M1042 - Disable or Remove Feature or Program]] | Em servidores que não requerem acesso SSH externo, desabilitar o serviço SSH completamente ou restringir via firewall para IPs de origem conhecidos; considerar uso de SSH bastions com autenticação multifator | | Centralização de chaves | Utilizar soluções de gerenciamento centralizado de chaves SSH (HashiCorp Vault, AWS Systems Manager Session Manager, CyberArk) que eliminam o uso de `authorized_keys` estáticos e permitem auditoria completa de sessões | ## Referências - [[g1006-earth-lusca|Earth Lusca]] - grupo de espionagem chinês documentado usando esta técnica contra alvos de telecomúnicações e governo - [[g1045-salt-typhoon|Salt Typhoon]] - ator de ameaça chinês com foco em telecomúnicações; usa injeção de chaves SSH para persistência em equipamentos de rede - [[g0139-teamtnt|TeamTNT]] - grupo especializado em cloud/Kubernetes; usa esta técnica como persistência padrão em campanhas de cryptojacking - [[s0468-skidmap|Skidmap]] - malware associado a esta técnica para persistência em ambientes Linux - [[t1098-account-manipulation|T1098 - Manipulação de Conta]] - técnica pai com outras sub-técnicas de abuso de conta - [[m1018-user-account-management|M1018 - User Account Management]] - controle de mitigação primário recomendado pelo MITRE *Fonte: [MITRE ATT&CK - T1098.004](https://attack.mitre.org/techniques/T1098/004)*