A vulnerabilidade CVE-2025-59374, associada a uma alteração não autorizada em builds do ASUS Live Update, entrou no catálogo KEV e exige retirada do cliente legado em ambientes que ainda dependem da ferramenta.
| Componente | ASUS Live Update, cliente de atualização automática usado em dispositivos ASUS. |
| Vetor | Distribuição de versões modificadas sem autorização, introduzidas por comprometimento de cadeia de suprimentos em servidores usados pelo fluxo de atualização. |
| Impacto | CVE-2025-59374 tem pontuação CVSS 9.3 e pode levar dispositivos que atendam a condições específicas de seleção a executar ações não pretendidas. |
| Prioridade | Inventariar instalações do ASUS Live Update, remover o cliente em fim de suporte e, quando a remoção imediata não for possível, garantir versão 3.6.8 ou superior enquanto a descontinuação é concluída. |
| Versões | A correção histórica foi indicada na versão 3.6.8; o último release informado é 3.6.15, e o suporte do cliente terminou em 4 de dezembro de 2025. |
| Prazo | Agências FCEB que ainda usam a ferramenta devem descontinuar o uso até 7 de janeiro de 2026. |
A vulnerabilidade CVE-2025-59374 foi adicionada ao catálogo de Vulnerabilidades Conhecidas Exploradas da CISA após evidência de exploração ativa contra o ASUS Live Update. A falha recebeu pontuação CVSS 9.3 e é descrita como uma vulnerabilidade de código malicioso embutido, introduzida por comprometimento de cadeia de suprimentos. O ponto central não é uma exploração tradicional disparada por uma requisição externa contra um serviço exposto, mas a distribuição de builds do próprio cliente de atualização com modificações não autorizadas. Isso altera a forma de resposta: além de corrigir versão, as equipes precisam tratar a ferramenta de atualização como componente potencialmente comprometido no inventário de endpoint.
A descrição técnica disponível delimita o impacto a dispositivos que instalaram versões comprometidas e que também atendiam a condições específicas de seleção. O histórico associado ao caso indica uma campanha revelada em 2019, conhecida como Operation ShadowHammer, na qual servidores relacionados ao Live Update foram comprometidos e artefatos trojanizados circularam entre junho e novembro de 2018. A campanha teria buscado um conjunto restrito de alvos, selecionados por endereços MAC de adaptadores de rede, com uma lista embutida contendo mais de 600 identificadores únicos. Esse detalhe é relevante para defesa porque reduz a utilidade de conclusões binárias simples: um ambiente pode ter recebido o cliente modificado sem necessariamente ter atendido aos critérios de ativação.
O fluxo técnico documentado começa no comprometimento de servidores usados para entregar atualizações do ASUS Live Update. A partir desse ponto, determinadas versões do cliente foram distribuídas com modificações não autorizadas. Em um modelo comum de atualização automática, o endpoint confia no canal do fornecedor para receber software legítimo; quando esse canal é comprometido, a execução passa a ocorrer dentro de um caminho que costuma ser permitido por controles de aplicação, listas de confiança, proxy e EDR. Por isso, a cadeia de suprimentos é o vetor dominante nesta falha, e não um anexo de phishing, uma exploração remota direta ou uma credencial vazada.
A lógica de seleção informada torna a campanha mais seletiva. Os builds trojanizados continham uma lista rígida de endereços MAC e buscavam identificar máquinas dentro desse conjunto. Apenas dispositivos que instalavam as versões comprometidas e correspondiam às condições de segmentação eram descritos como afetados pelas ações não pretendidas. O material analisado não fornece payload final, domínio de comando e controle, hash, caminho de arquivo, chave de registro ou comportamento pós-comprometimento específico; portanto, a análise defensiva deve permanecer focada no que está confirmado: presença do cliente ASUS Live Update, versão instalada, histórico de instalação ou atualização no intervalo relevante, execução de builds não autorizados e decisão de retirar um componente que chegou ao fim do suporte.
A correção histórica mencionada está na versão 3.6.8 do ASUS Live Update, enquanto o último release informado é 3.6.15. Mesmo assim, a situação atual é agravada pelo fim de suporte declarado em 4 de dezembro de 2025. Em termos operacionais, isso muda a prioridade de uma atualização pontual para a descontinuação planejada. Um cliente sem suporte tende a deixar de receber manutenção regular, correções futuras e validações de segurança compatíveis com o ciclo de vida esperado para ambientes corporativos.
A superfície afetada inclui estáções e dispositivos ASUS que mantêm o ASUS Live Update instalado, especialmente quando o componente permaneceu no ambiente por ciclos longos de imagem corporativa, reinstalação de fabricante ou manutenção local. O risco é mais relevante em endpoints nos quais a atualização automática tenha sido mantida com privilégios suficientes para instalar componentes, alterar software do sistema ou disparar rotinas em nome do usuário ou do fabricante. A existência de exploração ativa no catálogo KEV eleva a urgência para ambientes governamentais e para organizações que usam o KEV como referência de priorização.
A análise também precisa separar três grupos: máquinas com versões anteriores à correção 3.6.8, máquinas com versões 3.6.8 ou superiores ainda em uso e máquinas sem o cliente instalado. O primeiro grupo exige resposta mais severa, porque pode representar exposição histórica ao build modificado. O segundo ainda carrega risco de ciclo de vida, já que o cliente chegou ao fim de suporte mesmo quando está em versão posterior. O terceiro grupo deve ser usado como estado desejado para novas imagens, políticas de hardening e baselines de endpoint.
- Endpoints ASUS com ASUS Live Update instalado ou preservado em imagens antigas de sistema.
- Instalações que passaram por atualizações do cliente no período associado à campanha, entre junho e novembro de 2018, quando esse dado estiver disponível.
- Ambientes que ainda usam o Live Update após o fim de suporte declarado em 4 de dezembro de 2025.
- Agências FCEB e organizações que seguem priorização KEV, com prazo de descontinuação até 7 de janeiro de 2026.
O hunting deve começar por inventário confiável de software, porque a presença do ASUS Live Update é o ponto de ancoragem mais concreto. Consultas em ferramentas de gestão de ativos, EDR, MDM, SCCM ou inventário local devem identificar nome do produto, versão instalada, data de instalação, caminho de execução e eventos recentes do processo de atualização. Em paralelo, equipes podem procurar evidências históricas em imagens antigas, snapshots, logs de instalação e repositórios internos de pacotes, principalmente quando a organização mantém artefatos de fabricante em caches, compartilhamentos de implantação ou catálogos de software.
A telemetria de endpoint deve priorizar execução do cliente, criação ou substituição de binários associados ao Live Update, alterações de serviço e conexões de rede originadas pelo processo de atualização. Como o contexto não fornece domínios, hashes nem payloads, não é adequado criar IoCs artificiais. O melhor caminho é usar sinais comportamentais e administrativos: versão vulnerável ou obsoleta, execução inesperada em máquinas que não deveriam mais ter o componente, instalação fora do processo de gestão de mudanças e divergência entre o inventário declarado e o estado real do endpoint.
Para resposta a incidente, o fato de a campanha histórica ter usado seleção por MAC exige correlação com inventário de hardware. Caso a organização encontre builds antigos suspeitos, a equipe deve preservar metadados de arquivo, data de instalação, origem do pacote e identificadores de adaptadores de rede sem publicar valores sensíveis. A investigação deve documentar se a máquina apenas possuía o componente ou se havia evidência de execução do build modificado e de atendimento às condições de seleção descritas.
- Presença de ASUS Live Update, versão instalada e data de instalação em inventários de endpoint.
- Execução recente do processo de atualização em máquinas onde a ferramenta deveria estar removida.
- Artefatos antigos do Live Update em caches de implantação, imagens corporativas ou repositórios internos.
- Eventos de instalação ou substituição do cliente sem mudança aprovada.
- Correlação entre histórico de atualização e hardware de rede quando houver suspeita de exposição ao build modificado.
A mitigação principal é retirar o ASUS Live Update de ambientes que ainda dependem do cliente, em linha com o fim de suporte e com a exigência de descontinuação para agências FCEB até 7 de janeiro de 2026. Quando a remoção imediata não for viável por dependência operacional, a organização deve confirmar que a versão instalada é 3.6.8 ou superior enquanto executa o plano de desativação. Essa medida intermediária não deve ser tratada como destino final, porque o último release informado é 3.6.15 e o produto já não tem suporte ativo.
A resposta deve incluir validação de inventário após a remoção, bloqueio de reinstalação por políticas de software, revisão de imagens de sistema que ainda tragam o cliente e limpeza de pacotes antigos em compartilhamentos de implantação. Também é importante revisar exceções de EDR, proxy e controle de aplicação que concedam confiança ampla ao Live Update apenas por se tratar de ferramenta do fabricante. Em incidentes de cadeia de suprimentos, permissões herdadas para atualizadores de fornecedor podem permitir execução com menos atrito do que softwares desconhecidos.
Equipes de segurança devem registrar a decisão de risco, os grupos de ativos afetados, o estado de versão e a evidência de remoção. Para endpoints com histórico compatível com a janela da campanha, a investigação deve ser conduzida com preservação de evidências e sem assumir impacto além do que os dados demonstram. O contexto confirmado sustenta comprometimento de cadeia de suprimentos, builds modificados, segmentação por MAC e possibilidade de ações não pretendidas em dispositivos selecionados; não sustenta, por si só, afirmar vazamento de dados, movimentação lateral ou payload específico sem telemetria adicional do ambiente.
- Remover o ASUS Live Update de endpoints gerenciados e impedir reinstalação por política.
- Confirmar versão 3.6.8 ou superior apenas como controle temporário quando a retirada imediata não for possível.
- Atualizar imagens corporativas para excluir o cliente em fim de suporte.
- Revisar caches, pacotes internos e catálogos de distribuição que possam reinstalar builds antigos.
- Correlacionar inventário, logs de instalação e execução do cliente antes de concluir se houve exposição efetiva.
0 Comentários