t1563-001-ssh-hijacking

# T1563.001 - SSH Hijacking > **Técnica pai:** [[t1563-remote-service-session-hijacking|T1563 - Remote Service Session Hijacking]] ## Descrição **T1563.001 - SSH Hijacking** é uma subtécnica de [[lateral-movement|Movimentação Lateral]] na qual adversários sequestram sessões SSH legítimas e já estabelecidas para se mover lateralmente em ambientes Linux e macOS - sem precisar criar novas conexões, sem autenticação adicional e, muitas vezes, sem deixar rastros nos logs de autenticação convencionais. O SSH (Secure Shell) é o protocolo padrão de acesso remoto em sistemas Unix-like. Quando um usuário se autentica via **chave pública**, o agente SSH (`ssh-agent`) armazena a chave privada descriptografada em memória e a expõe via socket Unix (tipicamente em `/tmp/ssh-XXXXXXXX/agent.PPID`). O socket permite que outros processos solicitem operações criptográficas sem jámais ver a chave privada - e é exatamente este socket que um adversário com acesso root pode abusar. A diferença fundamental em relação ao uso convencional do [[t1021-004-ssh|T1021.004 - SSH]] é que esta técnica **não cria uma nova sessão autenticada**. Em vez disso, injeta comandos em uma sessão existente ou redireciona o socket do agente para uma sessão controlada pelo atacante - tornando a atividade invisível para sistemas que monitoram apenas novas autenticações SSH. ### Contexto Brasil e LATAM Em ambientes de nuvem e infraestrutura como código (IaC), que crescem aceleradamente no Brasil, o SSH Hijacking representa risco elevado. Times de DevOps de grandes bancos, fintechs e provedores de telecomúnicações brasileiros operam com múltiplas sessões SSH abertas simultaneamente para servidores de produção em AWS, Azure e GCP. Um atacante que compromete um bastion host - o ponto central de acesso SSH - pode sequestrar dezenas de sessões ativas de administradores privilegiados. O malware [[s1220-medusa|MEDUSA]] utiliza esta técnica entre seus vetores de movimentação lateral. Grupos de [[ransomware]] operando no Brasil têm demonstrado conhecimento de ambientes Linux/cloud, tornando esta técnica uma preocupação crescente para operações de segurança no [[financial|setor financeiro]] e de [[telecommunications|telecomúnicações]]. --- ## Attack Flow ```mermaid graph TB A([Adversário com root]) --> B[Localiza sockets SSH-agent ativos /tmp/ssh-*/agent.*] B --> C{{"T1563.001 SSH Hijacking"}}:::highlight C --> D[Exporta SSH_AUTH_SOCK para o socket da vítima] D --> E[ssh -A host-destino sem nova autenticação] C --> F[Injeção direta no pty via /proc/PID/fd] F --> G[Execução de comandos na sessão da vítima] E --> H[Lateral Movement para hosts confiáveis] G --> H classDef highlight fill:#e74c3c,color:#fff ``` --- ## Como Funciona **Passo 1 - Identificação de sessões e sockets ativos** Com acesso root no host comprometido, o adversário enumera processos SSH ativos e localiza os sockets do agente. Comandos típicos: ```bash # Listar processos SSH ativos ps aux | grep ssh # Encontrar sockets do ssh-agent find /tmp -name "agent.*" 2>/dev/null # Via /proc - listar variáveis de ambiente de processos SSH for pid in $(pgrep -x sshd); do cat /proc/$pid/environ 2>/dev/null | tr '\0' '\n' | grep SSH_AUTH_SOCK done ``` **Passo 2 - Sequestro do socket SSH-agent** O adversário redireciona a variável `SSH_AUTH_SOCK` para o socket da sessão legítima do usuário-alvo. Isso permite usar as chaves privadas carregadas na memória do agente da vítima sem jámais extraí-las: ```bash # Apontar para o socket do agente da vítima export SSH_AUTH_SOCK=/tmp/ssh-XYZABC/agent.1234 # Listar chaves disponíveis no agente sequestrado ssh-add -l # Conectar a hosts confiáveis usando as chaves da vítima ssh -A [email protected] ``` **Passo 3 - Movimentação lateral sem rastros de autenticação** Como a conexão utiliza uma sessão ou agente já autenticado, os logs de destino registram apenas uma conexão SSH de um host confiável (o bastion ou o host do administrador legítimo) - sem nova autenticação, sem novo par de chaves. O adversário pode executar comandos, transferir arquivos e estabelecer persistência nos hosts de destino, tudo aparentando ser tráfego legítimo do administrador. --- ## Detecção ### Event IDs / Artefatos de Log (Linux) | Fonte | Artefato | Indicador de Comprometimento | |-------|----------|------------------------------| | `/var/log/auth.log` | `Accepted publickey` | Autenticações SSH de origem inesperada ou fora do horário padrão | | `/var/log/secure` | `session opened` | Sessões abertas para hosts internos a partir de bastion em horário anômalo | | `auditd` | `syscall=connect` | Chamadas de sistema `connect()` originadas de processo com `SSH_AUTH_SOCK` externo | | `auditd` | `syscall=open` / `path=/tmp/ssh-*` | Abertura de sockets de agente SSH por processo diferente do dono do socket | | Shell history | `.bash_history`, `.zsh_history` | Comandos `ssh-add -l`, `export SSH_AUTH_SOCK=` executados por root | | `ps aux` / `/proc` | `sshd: [priv]` | Processos SSH privilegiados com variáveis de ambiente suspeitas | ### Regra Sigma ```yaml title: Acesso suspeito a socket SSH-agent por processo diferente do dono id: 3a7f9c2e-1b4d-4e8a-b3c0-5f2d8e1a6c4b status: experimental description: > Detecta tentativas de acesso a sockets do ssh-agent (/tmp/ssh-*/agent.*) por processos cujo UID difere do proprietário do socket - indicativo de SSH Hijacking. references: - https://attack.mitre.org/techniques/T1563/001 author: RunkIntel daté: 2026/03/24 tags: - attack.lateral_movement - attack.t1563.001 logsource: product: linux service: auditd detection: selection: type: SYSCALL syscall: connect key: ssh_agent_access filter_owner: # Filtrar acessos do próprio dono do socket auid: same_as_socket_uid socket_path: name|contains: '/tmp/ssh-' condition: selection and socket_path and not filter_owner falsepositives: - Ferramentas de gestão de sessões SSH legítimas (tmux, screen com SSH agent forwarding) - Scripts de automação com agent forwarding explicitamente configurado level: high ``` > [!warning] Atenção para ambientes cloud no Brasil > Em bastion hosts da AWS, GCP ou Azure utilizados por times brasileiros, habilite **auditd** com regras para monitorar acesso ao diretório `/tmp/ssh-*`. Muitas organizações monitoram apenas logs de autenticação (`auth.log`) e ficam cegos a este tipo de movimentação lateral. O Amazon GuardDuty e o Microsoft Defender for Cloud possuem detectores específicos para comportamentos SSH anômalos em instâncias Linux. --- ## Mitigação | Controle | Mitigação MITRE | Implementação para Organizações Brasileiras | |----------|----------------|---------------------------------------------| | Restringir permissões do socket | [[m1022-restrict-file-and-directory-permissions\|M1022]] | Garantir que `/tmp/ssh-*/agent.*` tenha permissão `600` e pertença exclusivamente ao usuário da sessão; implementar via PAM ou script de inicialização de sessão | | Desabilitar agent forwarding | [[m1042-disable-or-remove-feature-or-program\|M1042]] | Em `sshd_config`: `AllowAgentForwarding no` - desabilitar globalmente e permitir apenas onde estritamente necessário; em bastion hosts, nunca habilitar forwarding para hosts de produção | | Política de rotação de chaves | [[m1027-password-policies\|M1027]] | Rotacionar chaves SSH regularmente (máx. 90 dias); usar chaves FIDO2/hardware (YubiKey) em contas privilegiadas - padrão recomendado pelo BACEN para ambientes financeiros | | Gestão de contas privilegiadas | [[m1026-privileged-account-management\|M1026]] | Implementar PAM (Privileged Access Management) como CyberArk, Delinea ou HashiCorp Vault para gerenciar sessões SSH privilegiadas; gravar sessões para auditoria; usar acesso just-in-time | | Monitoramento de auditd | Detecção | Configurar regras auditd para alertar acesso a `/tmp/ssh-*` por processos root; integrar com SIEM (Splunk, Elastic Security) | --- ## Threat Actors e Contexto ### [[s1220-medusa|MEDUSA]] (Ransomware Group) O grupo operador do ransomware [[s1220-medusa|MEDUSA]] utiliza SSH Hijacking como técnica de movimentação lateral em ambientes Linux corporativos. O grupo tem histórico de ataques a infraestruturas críticas e organizações do [[financial|setor financeiro]] e educação - setores com presença significativa no Brasil. > [!note] Relação com outras técnicas > T1563.001 é frequentemente encadeada com: > - [[t1078-valid-accounts|T1078 - Valid Accounts]] - comprometer credenciais iniciais para acesso ao primeiro host > - [[t1021-004-ssh|T1021.004 - SSH]] - uso convencional de SSH para acesso inicial antes do hijacking > - [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]] - buscar chaves SSH privadas armazenadas em disco (`~/.ssh/id_rsa`) > - [[t1087-account-discovery|T1087 - Account Discovery]] - enumerar usuários com sessões SSH ativas antes de selecionar alvo --- ## Software Associado | Malware | Tipo | Uso da Técnica | |---------|------|----------------| | [[s1220-medusa\|MEDUSA]] | Ransomware Linux | Movimento lateral em ambientes corporativos Linux via sequestro de agente SSH | --- *Fonte: [MITRE ATT&CK - T1563.001](https://attack.mitre.org/techniques/T1563/001)*