t1021-004-ssh - RunkIntel

# T1021.004 - SSH ## Técnica Pai Esta é uma sub-técnica de [[t1021-remote-services|T1021 - T1021 - Remote Services]]. ## Descrição **T1021.004 - SSH** é uma subtécnica de [[t1021-remote-services|T1021 - Remote Services]] que descreve o uso de contas válidas ([[t1078-valid-accounts|T1078]]) para autenticar em sistemas remotos via Secure Shell (SSH), o protocolo padrão de acesso remoto em ambientes Linux, macOS e ESXi. Após autenticação bem-sucedida, o adversário opera com os privilégios da conta comprometida, podendo executar comandos arbitrários, transferir arquivos, implantar malware e pivotar para outros sistemas na rede. SSH suporta dois métodos de autenticação principais: senha e par de chaves pública/privada. Adversários exploram ambos: ataques de força bruta e credential stuffing contra autenticação por senha, e roubo ou implantação de chaves SSH ([[t1098-004-ssh-authorized-keys|T1098.004 - SSH Authorized Keys]]) para autenticação persistente sem senha. Em ambientes VMware ESXi, o SSH pode ser habilitado via `vim-cmd hostsvc/enable_ssh` ou pelo vCenter, representando um vetor crítico especialmente relevante dado o crescente número de ransomwares que visam hipervisores ESXi para maximizar impacto. No Brasil e América Latina, esta técnica é extremamente prevalente dado o vasto parque de servidores Linux em provedores de internet (ISPs), e-commerce, agro-tech, fintechs e infraestrutura de nuvem. O grupo [[g0139-teamtnt|TeamTNT]] realizou campanhas massivas de cryptomining que comprometeram servidores Linux brasileiros via SSH com credenciais padrão ou fracas. O [[g0032-lazarus-group|Lazarus Group]] usa SSH para movimentação lateral em redes financeiras Linux, e grupos de ransomware como [[g1015-scattered-spider|Scattered Spider]] exploram SSH em ambientes ESXi para implantação de ransomware em hipervisores. > [!warning] Relevância Brasil/LATAM > O Brasil possui um dos maiores parques de servidores Linux da América Latina. ISPs regionais, provedores de hosting, operadoras de e-commerce e empresas de agro-tech frequentemente expõem SSH diretamente à internet com credenciais fracas. O CERT.br documenta regularmente campanhas de brute-force SSH contra prefixos de endereço IP brasileiros. Ataques de ransomware ESXi (grupos como Royal, RansomHub) comprometeram ambientes de virtualização de empresas brasileiras via SSH habilitado no hipervisor. --- ## Attack Flow ```mermaid graph TB A([Acesso Inicial Brute-force / Credenciais Roubadas]) --> B([Credenciais SSH Válidas T1078 / T1098.004]) B --> C([Autenticação SSH Porta 22 / Porta Customizada]) C --> T1021004([T1021.004 SSH Lateral Movement]):::highlight T1021004 --> E([Execução Pós-Acesso Implante / Coleta / Pivô]) E --> F([Impacto Cryptomining / Ransomware / Exfiltração]) classDef highlight fill:#e74c3c,color:#fff,stroke:#c0392b,stroke-width:2px ``` --- ## Como Funciona **Passo 1 - Obtenção de credenciais SSH ou chaves válidas** O adversário obtém acesso SSH por três vetores principais: (a) brute-force e credential stuffing contra servidores com autenticação por senha habilitada - especialmente eficaz contra contas root ou de serviço com senhas fracas; (b) roubo de chaves privadas SSH armazenadas em sistemas já comprometidos (tipicamente em `~/.ssh/id_rsa` ou `~/.ssh/id_ed25519`); (c) implantação de chaves públicas no arquivo `~/.ssh/authorized_keys` do alvo após comprometimento inicial, garantindo acesso persistente sem senha. O [[g0032-lazarus-group|Lazarus Group]] frequentemente usa o método (b) para pivotar lateralmente a partir de um servidor de desenvolvimento comprometido para sistemas de produção. **Passo 2 - Conexão SSH e reconhecimento no sistema alvo** Com credenciais em mãos, o adversário conecta ao alvo via `ssh usuario@host` ou usando a chave privada (`ssh -i chave.pem usuario@host`). Ferramentas como [[s0154-cobalt-strike|Cobalt Strike]] (SOCKS proxy + proxychains), [[s1187-regeorg|reGeorg]] e [[s0363-empire|Empire]] automatizam o tunneling SSH para criar cadeias de pivôs. Em ambientes ESXi, o adversário habilita SSH no hipervisor e acessa o datastore para implantar VMs maliciosas ou executar comandos `esxcli` diretamente nos volumes de armazenamento. **Passo 3 - Execução de ações maliciosas e persistência** Após autenticação, o adversário executa sua missão: o [[g0139-teamtnt|TeamTNT]] implanta miners de criptomoeda ([[s0599-kinsing|Kinsing]]) e scripts de worm que se propagam automaticamente pela rede varrendo faixas de IP por SSH; o [[g0032-lazarus-group|Lazarus Group]] exfiltra dados financeiros; grupos de ransomware como [[g1015-scattered-spider|Scattered Spider]] e [[g1046-storm-1811|Storm-1811]] implantam ransomware nos datastores ESXi para criptografar VMs em massa. Persistência é garantida via crontab, serviços systemd ou adição de chave pública ao `authorized_keys`. --- ## Detecção ### Fontes de Eventos Recomendadas | Fonte | Evento / Indicador | Prioridade | |---|---|---| | `/var/log/auth.log` (Debian/Ubuntu) | Múltiplas tentativas de autenticação falhas seguidas de sucesso (brute-force bem-sucedido) | Crítica | | `/var/log/secure` (RHEL/CentOS) | Logon root via SSH de IP externo | Crítica | | auditd | `execve` pós-login SSH com comandos de reconhecimento (`id`, `whoami`, `uname`, `ifconfig`) | Alta | | SSH server logs | Login de usuário não interativo / conta de serviço via SSH | Alta | | Firewall / NetFlow | Conexões SSH originando de hosts internos inesperados (movimentação lateral interna) | Alta | | ESXi syslog | Habilitação do serviço SSH no hipervisor fora de jánela de manutenção | Crítica | ### Regra Sigma - Brute-force SSH Bem-sucedido ```yaml title: Brute-force SSH Bem-sucedido - Login Após Múltiplas Falhas id: t1021-004-ssh-brute-force-success status: stable description: > Detecta padrão de brute-force SSH bem-sucedido: múltiplos logins falhos do mesmo IP seguidos de autenticação bem-sucedida em jánela de 10 minutos. Indicativo de T1021.004 via credential stuffing. logsource: product: linux service: auth detection: failed_logins: keywords: - ‘Failed password for’ - ‘Invalid user’ successful_login: keywords: - ‘Accepted password for’ - ‘Accepted publickey for’ timeframe: 10m condition: failed_logins | count() by src_ip > 10 | then successful_login falsepositives: - Usuários esquecendo senha com múltiplas tentativas legítimas - Scripts de automação com credenciais incorretas temporariamente level: high tags: - attack.lateral_movement - attack.t1021.004 - attack.credential_access --- title: Implantação de Chave SSH Não Autorizada (T1098.004) id: t1021-004-ssh-authorized-keys-modification status: stable description: > Detecta modificação do arquivo authorized_keys, potencial indicador de implantação de backdoor SSH persistente (T1098.004 + T1021.004). logsource: product: linux category: file_event detection: selection: TargetFilename|endswith: ‘/.ssh/authorized_keys’ filter_legitimate: Image|endswith: - ‘/ssh-keygen’ - ‘/ansible’ condition: selection and not filter_legitimate falsepositives: - Gestão legítima de chaves SSH via Ansible, Puppet, Chef - Administradores adicionando chaves manualmente level: high tags: - attack.persistence - attack.lateral_movement - attack.t1098.004 - attack.t1021.004 ``` --- ## Mitigação | Controle | Descrição | Aplicabilidade Brasil/LATAM | |---|---|---| | Desabilitar autenticação por senha no SSH ([[m1042-disable-or-remove-feature-or-program\|M1042]]) | Configurar `PasswordAuthentication no` no `sshd_config`; exigir autenticação por chave pública | Medida mais impactante para reduzir brute-force; crítica para servidores expostos à internet | | MFA para SSH ([[m1032-multi-factor-authentication\|M1032]]) | Implementar autenticação de dois fatores via Google Authenticator (PAM) ou certificados SSH com válidade curta | Recomendado para ambientes com múltiplos administradores; adotado por bancos e fintechs brasileiros | | Gestão de contas de usuário ([[m1018-user-account-management\|M1018]]) | Desativar login SSH para root (`PermitRootLogin no`); usar contas individuais com `sudo`; remover contas de serviço sem uso | Padrão CIS Benchmarks para hardening Linux - aplicável a qualquer servidor Ubuntu/RHEL | | Restrição de acesso SSH por IP/rede | Usar `AllowUsers`, `AllowGroups` no `sshd_config` ou firewall (iptables/nftables) para limitar quais IPs podem conectar na porta 22 | Fundamental para servidores em cloud pública (AWS, Azure, GCP) - usar Security Groups e VPN | | Rotação e auditoria de chaves SSH | Manter inventário de todas as chaves autorizadas; revogar chaves de ex-funcionários; rotacionar chaves de acesso a sistemas críticos anualmente | Crítico para empresas com alta rotatividade de equipe de infra - implementar com HashiCorp Vault ou AWS Secrets Manager | | Monitoramento de authorized_keys | Usar auditd ou IDS para detectar modificações no arquivo `~/.ssh/authorized_keys` em tempo real | Detecta implantação de backdoors SSH persistentes - especialmente relevante para servidores de produção | | Desabilitar SSH no ESXi quando não necessário | Desligar o serviço SSH no hipervisor por padrão; habilitar apenas durante jánelas de manutenção com aprovação formal | Mitiga ransomware ESXi; recomendado para ambientes de virtualização de médias e grandes empresas brasileiras | --- ## Threat Actors e Software > [!danger] Principais Operadores desta Técnica ### [[g0032-lazarus-group|Lazarus Group]] APT norte-coreano com histórico extenso de operações financeiras contra bancos, exchanges de criptomoeda e fintechs globalmente. Usa SSH como vetor primário de movimentação lateral em ambientes Linux/macOS, frequentemente aproveitando chaves SSH roubadas de sistemas de desenvolvimento para alcançar servidores de produção. Responsável por ataques ao setor financeiro em LATAM, incluindo o roubo do Banco de Bangladesh via SWIFT. ### [[g0139-teamtnt|TeamTNT]] Grupo especializado em cryptomining e roubo de credenciais cloud, com campanhas massivas contra servidores Linux brasileiros. Propaga-se via SSH com credential stuffing usando listas de credenciais padrão (root/root, ubuntu/ubuntu, admin/admin). Ao comprometer um servidor, implanta o malware [[s0599-kinsing|Kinsing]] para mineração de Monero e scripts de worm que varrem subredes por novos alvos SSH. ### [[g1015-scattered-spider|Scattered Spider]] Grupo ativo em ataques de engenharia social e ransomware, com operações documentadas contra infraestrutura ESXi. Usa SSH para acessar hipervisores VMware e implantar ransomware diretamente nos datastores, criptografando VMs em massa para maximizar impacto em empresas com ambientes de virtualização centralizados. ### [[g1046-storm-1811|Storm-1811]] Afiliado de ransomware RaaS com operações recentes. Combina [[t1078-valid-accounts|contas válidas]] com SSH para movimentação lateral em ambientes híbridos Linux/Windows, frequentemente aproveitando credenciais de jump servers ou bastion hosts comprometidos. ### [[g0046-fin7|FIN7]] Grupo criminoso financeiramente motivado com operações contra varejo, restaurantes e setor financeiro. Usa SSH como parte de um toolkit de movimentação lateral em ambientes Linux, frequentemente em combinação com [[s0154-cobalt-strike|Cobalt Strike]] para gerenciar implantes em redes corporativas mistas. ### [[g0117-fox-kitten|Fox Kitten]] APT iraniano especializado em exploração de VPNs e acesso remoto. Após comprometer dispositivos de borda, usa SSH para movimentação lateral na rede interna, especialmente em ambientes com servidores Linux de administração de rede. ### Software Associado | Software | Tipo | Uso em T1021.004 | |---|---|---| | [[s0154-cobalt-strike\|Cobalt Strike]] | Framework C2 | SOCKS proxy + proxychains para pivoting via SSH | | [[s0363-empire\|Empire]] | Framework C2 | Módulo SSH para movimentação lateral em Linux/macOS | | [[s1187-regeorg\|reGeorg]] | Ferramenta de pivoting | Tunneling HTTP/HTTPS para criar proxy SOCKS via SSH | | [[s0599-kinsing\|Kinsing]] | Malware cryptominer | Propagação worm via SSH com credential stuffing | --- *Fonte: [MITRE ATT&CK - T1021.004](https://attack.mitre.org/techniques/T1021/004)*