Vulnerabilidade zero-day: o que fazer nas primeiras horas

O que é uma vulnerabilidade zero-day e por que as primeiras horas importam

Uma vulnerabilidade zero-day é uma falha de segurança que se torna conhecida, ou passa a ser explorada, antes que o fabricante tenha uma correção disponível. O nome vem justamente disso: a equipe de TI tem "zero dias" para se preparar. Quando a notícia aparece no boletim do fabricante, num alerta do CERT.br ou num catálogo como o KEV (Known Exploited Vulnerabilities) da CISA, é comum que grupos criminosos já estejam varrendo a internet atrás de sistemas expostos.

Casos como o Log4Shell (CVE-2021-44228), as falhas do Exchange Server conhecidas como ProxyLogon e a exploração em massa do MOVEit Transfer mostraram um padrão que se repete. Entre a divulgação e os primeiros ataques automatizados costumam passar poucas horas. Empresas que demoraram a reagir foram comprometidas mesmo depois que o patch já existia, porque o invasor tinha entrado antes e deixado acesso persistente.

Por isso, a resposta a um zero-day não começa quando a correção sai. Ela começa no momento em que o alerta chega. As primeiras horas servem para responder três perguntas: a empresa usa o sistema afetado? Ele está exposto? Há sinal de que alguém já explorou a falha? O resto da resposta parte dessas três respostas.

Hora zero: confirmar a ameaça e acionar a equipe certa

O primeiro passo é separar fato de ruído. Em dias de alerta crítico circulam muitos posts alarmistas, provas de conceito falsas e informações desencontradas sobre versões afetadas. A fonte de referência deve ser sempre o comunicado oficial do fabricante, o registro da CVE na NVD e os alertas de órgãos reconhecidos. Anote o identificador da falha, os produtos e versões afetados, as condições para a exploração (se exige autenticação, se depende de uma configuração específica) e se há relato de exploração ativa.

Com a ameaça confirmada, acione o plano de resposta a incidentes. Se a empresa não tem um plano formal, defina na hora quem decide, quem executa e quem comunica. Um zero-day crítico não deve ficar nas mãos de uma só pessoa, nem ser tratado como um chamado comum na fila do suporte. Os papéis mínimos são:

• Coordenador da resposta: centraliza as decisões, define prioridades e registra o que foi feito e quando.
• Responsável técnico: levanta a exposição, aplica as mitigações e acompanha os logs.
• Ponto de contato com a gestão: informa a diretoria sobre riscos e decisões que afetam o negócio, como tirar um serviço do ar.
• Apoio jurídico ou de privacidade: entra se houver suspeita de acesso a dados pessoais, por causa das obrigações da LGPD.

Registrar tudo desde o início faz diferença. Um registro simples com horário, ação tomada, quem executou e o resultado vai servir para a análise posterior, para eventuais comunicações a clientes ou à ANPD e para melhorar o processo na próxima ocorrência.

Descobrir onde você está exposto

A pergunta mais difícil nas primeiras horas costuma ser a mais básica: onde esse software roda na empresa? Quem tem um inventário de ativos atualizado responde em minutos. Quem não tem perde horas procurando servidores esquecidos, appliances que ninguém documentou e bibliotecas embutidas em sistemas de terceiros. No caso do Log4Shell, muitas empresas descobriram que usavam o componente vulnerável sem saber, porque ele vinha dentro de produtos comerciais.

O levantamento deve seguir uma ordem lógica, começando pelo que tem mais chance de ser atacado primeiro:

1. Sistemas expostos à internet: firewalls, VPNs, gateways de e-mail, portais web, servidores de arquivos com acesso externo. São o alvo das varreduras automáticas.
2. Sistemas que guardam dados sensíveis ou críticos: ERP, banco de dados, controladores de domínio, servidores de backup.
3. Estações e servidores internos: importantes, mas em geral exigem que o invasor já tenha algum acesso à rede.
4. Fornecedores e serviços em nuvem: verifique se provedores de SaaS e parceiros que se conectam à sua rede usam o produto afetado e o que estão fazendo a respeito.

Ferramentas de varredura de vulnerabilidades, consultas ao agente de gerenciamento de endpoints e a lista de portas publicadas no firewall ajudam a acelerar esse trabalho. O resultado precisa ser uma lista concreta de quais ativos usam qual versão, se estão expostos ou não e quem é o responsável por cada um. Sem essa lista, as próximas etapas são feitas no escuro.

Mitigar sem patch: as medidas compensatórias

Se ainda não há correção, a meta é reduzir a superfície de ataque até que ela saia. Em geral, o próprio fabricante publica um procedimento de mitigação temporária junto com o alerta: desativar um recurso, alterar uma configuração, bloquear um caminho de URL. Essa orientação deve ser a primeira opção, porque foi pensada para a falha específica. Mesmo assim, vale testar em um ambiente controlado antes de aplicar em produção, já que algumas mitigações quebram funções que o negócio usa.

Além da recomendação do fabricante, há medidas compensatórias que funcionam para a maioria dos cenários:

• Restringir o acesso externo: limitar o serviço vulnerável a IPs conhecidos, colocá-lo atrás de VPN ou tirá-lo temporariamente da internet.
• Regras de WAF e IPS: fabricantes de firewall e de proteção web costumam publicar assinaturas para bloquear tentativas de exploração poucas horas após a divulgação. Confirme se as assinaturas estão atualizadas e em modo de bloqueio, não só de alerta.
• Segmentação de rede: isolar o sistema afetado para que um comprometimento não permita movimentação lateral até servidores críticos.
• Reforço de credenciais: exigir MFA, revisar contas administrativas e revogar sessões e tokens do sistema afetado quando houver suspeita.
• Desligar o que não é essencial: se o serviço vulnerável não é crítico para a operação, desativá-lo até a correção é a mitigação mais eficaz que existe.

Mitigação não é correção. Ela compra tempo e reduz o risco, mas o sistema continua vulnerável até que o patch seja aplicado e validado. Toda medida temporária precisa ter dono e data para ser revista.

Também é importante garantir que o backup esteja em dia antes de qualquer mudança mais profunda e que exista ao menos uma cópia isolada, fora do alcance da rede principal. Se a falha for explorada para implantar ransomware, essa cópia é o que vai permitir a recuperação.

Priorizar, caçar sinais de comprometimento e comunicar

Nem toda vulnerabilidade crítica tem a mesma urgência para a sua empresa. A nota CVSS indica a gravidade técnica, mas a priorização deve considerar o contexto: o sistema está exposto à internet? Há exploração ativa confirmada? O ativo guarda dados sensíveis ou sustenta uma operação essencial? Indicadores como a presença no catálogo KEV e a pontuação EPSS, que estima a probabilidade de exploração, ajudam a separar o que precisa de ação imediata do que pode seguir o ciclo normal de atualização.

Em paralelo à mitigação, a equipe técnica deve procurar sinais de que a falha já foi explorada. Como o zero-day pode ter sido usado antes da divulgação, aplicar a mitigação sem investigar pode deixar um invasor instalado na rede. Os pontos de verificação mais comuns são:

• Logs de acesso do sistema afetado com requisições anômalas ou padrões citados nos indicadores de comprometimento (IoCs) publicados pelo fabricante.
• Criação de contas, arquivos ou tarefas agendadas fora do padrão, especialmente em servidores expostos.
• Conexões de saída para endereços desconhecidos, que podem indicar canal de comando e controle.
• Alertas do antivírus ou EDR que tenham sido ignorados nos dias anteriores à divulgação.

A comunicação também faz parte da resposta. A diretoria precisa saber o tamanho do risco e as decisões que talvez afetem a operação. Se houver indício de acesso a dados pessoais, entra em cena a LGPD: a regulamentação da ANPD prevê prazo curto, de três dias úteis, para comunicar incidentes que possam causar risco ou dano relevante aos titulares. Avaliar isso cedo evita decisões apressadas no fim do prazo.

Depois do patch: fechar o ciclo e se preparar para o próximo

Quando a correção oficial for publicada, aplique-a seguindo a mesma ordem de prioridade do levantamento: primeiro os sistemas expostos e críticos, depois o restante. Valide se a atualização realmente foi instalada, conferindo a versão em cada ativo em vez de confiar apenas no status do console de gerenciamento. Em seguida, revise as mitigações temporárias. Algumas podem ser desfeitas, mas outras, como restringir o acesso administrativo pela internet, merecem virar configuração permanente.

Por fim, faça uma análise pós-incidente com a equipe. O que atrasou a identificação dos ativos afetados? O inventário estava completo? Quanto tempo levou para aplicar a mitigação? Havia backup isolado e testado? Essas respostas mostram onde investir para que o próximo zero-day, que certamente virá, seja tratado com mais rapidez. Empresas que mantêm inventário atualizado, gestão de patches contínua, monitoramento de logs e um plano de resposta testado conseguem reagir em horas, não em dias.

A Duk Informática & Cloud apoia empresas exatamente nesse ponto. Com mais de 18 anos de experiência, mais de 550 clientes atendidos e o status de Microsoft Gold Partner, a Duk atua como parceiro de TI na gestão de vulnerabilidades e na resposta a incidentes: inventário de ativos, monitoramento contínuo, aplicação de patches, backup em data center próprio em Alphaville e suporte 24/7 com SLA. Quando surge um alerta crítico, sua empresa não precisa descobrir sozinha onde está exposta nem o que fazer primeiro. Se quiser avaliar como está a preparação do seu ambiente para a próxima falha zero-day, fale com a equipe da Duk.