Se você acabou de descobrir que uma ferramenta de suporte pode ter sido o ponto de entrada do atacante, a primeira hora define o que você consegue preservar, quanto escopo pode limitar e se mantém opções forenses. Este artigo fornece um playbook operacional focado e priorizado para essa primeira hora — o que fazer, o que coletar e quais decisões importam.

Para quem é isto e o que este artigo entrega

Este texto é direcionado a TI, SOC e tratadores de incidentes que já operam ferramentas de suporte remoto (TeamViewer, AnyDesk, RDP, Tenvo, etc.). Não é um manual forense aprofundado — é um checklist operacional curto para executar na primeira hora quando o canal de suporte é o suspeito vetor. Você receberá uma sequência de triagem priorizada, artefatos concretos para capturar, cheques rápidos de indicadores, ações de contenção que evitam destruir evidências e um checklist breve de comunicação.

Triagem imediata: checklist priorizado (primeiros 0–60 minutos)

Não entre em pânico; aja na ordem. Velocidade importa mais que esperteza. Siga os passos na ordem — pular a preservação para bloquear tudo imediatamente torna as investigações mais difíceis.
Identifique as sessões e usuários suspeitos. Quem iniciou a sessão de suporte? Qual conta, nome de usuário ou dispositivo do técnico aparece nos logs de suporte? Anote carimbos de data/hora (UTC) e IDs de sessão antes de alterar qualquer coisa.
Preserve logs e evidências primeiro. Extraia os logs do servidor de acesso remoto, os logs do relay e quaisquer gravações de sessão. Se a ferramenta de suporte for gerenciada na nuvem, exporte os logs do console de administração imediatamente. Se necessário, faça um snapshot do sistema de suporte (memória, disco) após a exportação.
Isole, não destrua. Coloque o endpoint comprometido em quarentena da rede (VLAN, porta do switch ou bloqueio no firewall do host), mas evite desligá‑lo a menos que seja necessário. Você quer preservar processos, memória e conexões de rede abertas para análise forense.
Bloqueie o acesso adicional seletivamente. Revogue ou desative a conta de suporte específica ou a impressão digital do dispositivo usada pela sessão suspeita. Não revogue em massa todas as contas de suporte a menos que esteja preparado para o impacto operacional.
Gire credenciais e segredos expostos a esse dispositivo. Altere senhas, chaves de API e contas de serviço às quais o host comprometido ou a sessão tinha acesso — mas documente as mudanças com precisão para os investigadores.
Notifique stakeholders e abra um canal de incidente. Informe o responsável pelo incidente, jurídico/compliance e o CISO. Use um canal de incidente pré‑aprovado (chat ou ticket) e designe um único comandante do incidente para evitar ações duplicadas.

O que coletar e preservar (lista de evidências)

Coletar os artefatos certos na primeira hora preserva opções para avaliação de causa raiz e escopo. Priorize exportações que você pode fazer remotamente e de forma não destrutiva.

Logs do software de acesso remoto: timestamps de início/parada de sessão, IDs de sessão, IPs dos peers conectados, IDs de usuário/dispositivo, flag de uso de relay e quaisquer gravações de sessão.
Logs de autenticação: logs do IdP, logs de push/ticket de MFA e quaisquer logs de serviço SSO que mostrem a atividade da conta de suporte correlacionada com eventos de sessão.
Logs e memória do endpoint: Windows Event Log (Security e System), Linux /var/log/auth.log e syslog, listas de processos e imagem de memória se possível.
Capturas de rede: PCAPs da porta do switch do endpoint, do firewall upstream ou de um TAP. Capture pelo menos 60–120 segundos ao redor dos horários conhecidos da sessão se captura contínua não estiver disponível.
Logs de auditoria do relay/fornecedor: se a sessão passou por um relay gerenciado, exporte os logs de conexão do provedor de relay e as regiões/POPs utilizados.
Snapshots de configuração e políticas: configuração atual da ferramenta de suporte, listas de controle de acesso, membros de grupos, contas de administrador local e alterações de política recentes.

Win: wevtutil qe Security /q:"*[System[(EventID=4624)]]" /f:text > log_4624.txt
Linux: sudo journalctl --since '2026-10-13 09:00:00' --until '2026-10-13 10:00:00' > auth-window.log
Network: sudo tcpdump -i any -s 0 -w suspect.pcap host 198.51.100.23

Como determinar se a ferramenta de suporte foi o vetor

Nem toda sessão de suporte suspeita equivale a comprometimento. Esses cheques ajudam a determinar se a sessão foi uma ferramenta pós‑compromisso, o vetor inicial ou uma omissão benigna.

Tempo da sessão vs momento da detecção. Se a sessão começou antes da primeira detecção (alerta AV, criação de conta nova ou processo suspeito), é mais provável que tenha sido o vetor.
Anomalias de credenciais. Procure por novas impressões digitais de dispositivo, chaves de API novas ou uma conta de suporte recém‑criada. Verifique se a sessão usou SSO ou usuário/senha direto e se o MFA foi contornado ou não utilizado.
Relay vs conexão peer-to-peer direta. Determine se o cliente conectou diretamente peer‑to‑peer (NAT hole‑punch) ou via relay. Na maioria das ferramentas, o fallback para relay significa que o ponto de terminação do relay tem visibilidade do tráfego da sessão — capture esses logs de relay e os endpoints de conexão.
Atividade lateral concorrente. Se a sessão de suporte correlaciona com logins laterais, elevações de privilégio ou roubo de credenciais em minutos, a sessão provavelmente desempenhou papel no movimento do atacante.
Padrões de abuso da ferramenta. Verifique uso de CLI, transferências de arquivo iniciadas na sessão, inicialização de shells remotos ou comandos que baixam executáveis. Esses são sinais claros de alerta.

Ações de contenção que preservam evidências

A contenção na primeira hora é um equilíbrio: é preciso parar a atividade do atacante sem destruir evidências voláteis. Prefira movimentos direcionados e reversíveis.

Desative exatamente a conta de suporte ou o certificado do dispositivo comprometido. A maioria das ferramentas permite revogar um certificado de cliente ou desabilitar um usuário. Revogue a credencial comprometida em vez de reinstalar ou limpar o endpoint.
Bloqueie o tráfego de controle remoto de/para o endpoint na borda da rede. Aplique uma ACL ou uma regra de microsegmentação direcionada ao IP do endpoint e aos IPs de relay conhecidos da ferramenta de suporte. Ainda não limpe o host.
Coloque hosts afetados em quarentena. Mova‑os para uma VLAN isolada ou derrube o uplink. Preserve um caminho de gerenciamento se ainda precisar executar comandos forenses.
Preserve disco e memória se suspeitar de malware ativo. Se for necessária memória viva, realize um dump de RAM agora. Se não for possível, ao menos faça uma imagem de disco antes de reimagens.
Gire credenciais com logs. Gire segredos para serviços afetados, mas registre cada alteração claramente. Investigadores precisam de uma linha do tempo do que foi alterado e por quê.

Comunicação: quem avisar e o que dizer

Comunicações claras e rápidas reduzem confusão. Use sua matriz de notificação de incidentes e mantenha as mensagens factuais e curtas. Evite linguagem especulativa ("fomos violados") até que esteja confirmado.

Interno: responsável pelo incidente, SOC, operações de TI, jurídico/privacidade, RH (se dados de funcionários estiverem envolvidos) e seu sponsor executivo.
Externo: contato de suporte do provedor do relay gerenciado ou SaaS (abra um ticket de incidente e exporte os logs), provedores de serviço gerenciados e seu assessor jurídico de violação se dados regulados puderem ser afetados.
Clientes: somente após o escopo. Tenha modelos pré‑aprovados para "estamos investigando" e para notificações pós‑mitigação que atendam aos requisitos de conformidade.
Reguladores: se você estiver sob requisitos de notificação (GDPR, HIPAA, PCI), notifique o jurídico cedo e siga sua linha do tempo de notificação de violação.

Decida rápido: relay gerenciado vs self-hosting para a recuperação

Se o incidente mostra que o operador do relay poderia ver o tráfego da sessão, isso afeta risco e evidência. Para a maioria das equipes, um relay gerenciado (o relay gerenciado multi‑região da Tenvo por padrão) é a escolha certa: remove manutenção on‑call do relay, centraliza logs e fornece failover multi‑região. Tenvo fornece clientes nativos para Windows/macOS/Linux, um cliente em browser em beta público e um relay gerenciado com tiers Free $0 / Lite $2.99/mo / Pro $7.99/mo.

Self‑hosting é apropriado apenas se você tiver um requisito escrito que proíba infraestrutura de terceiros (residência de dados, regra de conformidade ou rede isolada). Self‑hosting adiciona custo operacional: você passa a ser responsável por uptime do relay, renovação de certificados, custódia de chaves e patching. Se estiver considerando self‑hosting após um incidente, leia as compensações de self‑hosting em Self-hosted remote desktop: the honest 2026 guide antes de se comprometer.

Checagens técnicas e comandos para executar a seguir (indicadores rápidos)

Esses cheques rápidos fornecem indicadores imediatos de atividade do atacante. Execute‑os a partir do endpoint (se seguro) ou de uma estação forense com imagem preservada.

Windows: IDs de evento — Autenticação: 4624 (logon), 4625 (logon falho), 4672 (privilégios especiais), 4688 (criação de processo). Verifique logs do PowerShell para scripts suspeitos (4104) e Sysmon (se implantado) para processos pais remotos.
Linux: sudo /var/log/auth.log para sessões sudo/ssh; verifique a lista de processos (ps auxww) e last -f /var/log/wtmp para logins recentes.
Rede: tcpdump ou tshark para conexões entre o endpoint e IPs de relay conhecidos. Procure por dumps de saída incomuns, DNS via resolvers incomuns e sessões TLS persistentes.
Artefatos de aplicação: IDs de sessão da ferramenta de suporte, logs de transferência de arquivos e entradas de transferência de clipboard. Exporte‑os antes de desinstalar o cliente.

Após contenção: remediação e hardening (próximas 24–72 horas)

Depois de conter e capturar evidências, execute a remediação e remova persistências do atacante.

Reimagine hosts afetados a partir de uma imagem base verificada (golden image), a menos que o host precise permanecer para trabalho forense em andamento.
Reemita todas as credenciais e chaves acessíveis a partir do host comprometido; gire contas de serviço, chaves SSH e tokens.
Exija autenticação mais forte para ferramentas de suporte: requerer SSO + MFA, listas de permissão por dispositivo e gates de aprovação de sessão. Veja remote access mfa: TOTP, push, passkeys, hardware para comparação de métodos.
Endureça logging de auditoria e retenção para que futuros incidentes sejam mais fáceis de investigar. Veja práticas recomendadas de logging em Remote Desktop Audit Logging.
Execute uma varredura completa de credenciais (senhas compartilhadas em chat, credenciais armazenadas, senhas salvas no navegador) e imponha uma janela de troca de credenciais.

Lições aprendidas e onde investir

Quando o incidente imediato estiver encerrado, faça um post‑mortem curto focado em causa raiz e lacunas operacionais. Investimentos típicos que reduzem risco e tempo de contenção incluem:

Restringir privilégios da ferramenta de suporte ao mínimo necessário e aplicar elevações just‑in‑time.
MFA adaptativa e listas de permissão por dispositivo para clientes de suporte.
Gravação automática de sessões e exportações imutáveis de auditoria para um SIEM externo.
Processos claros de offboarding e revogação de dispositivos — veja Remote access offboarding checklist para uma lista pronta.
Testar runbooks de incidente regularmente em simulações tabletop focadas em cenários de acesso remoto.

Notas finais sobre confiança e a verdade do relay

Seja explícito com sua equipe: uma conexão peer‑to‑peer direta é end‑to‑end entre os dois dispositivos, mas quando o tráfego recorre a um relay, o TLS termina naquele relay. Isso significa que qualquer organização que opere o relay pode acessar o tráfego da sessão se assim desejar ou for obrigada. Não presuma que relays sejam invisíveis — construa controles e exportações de logs de acordo. Se quiser um modelo de ameaça mais profundo para ferramentas remotas, nosso deep‑dive técnico é útil: Is Remote Desktop Secure? An Honest Threat Model.

Onde obter ajuda e o link de download

Se precisar de um relay gerenciado com logs centralizados e failover multi‑região, o relay gerenciado da Tenvo é a recomendação padrão, a menos que um requisito escrito force self‑hosting. Para recuperação prática: preserve evidências, abra tickets com seu fornecedor de relay imediatamente e siga o checklist de triagem acima. Quando estiver pronto, baixe clientes ou execute uma migração controlada do seu cliente atual em Baixar Tenvo.

Resposta a incidentes de acesso remoto: checklist da primeira hora