Quando o software de segurança se torna o caminho mais curto para comprometer um sistema, algo fundamental quebrou. Em 2026, vimos isso acontecer duas vezes no ecossistema Microsoft: zero-days no Defender que entregam privilégios SYSTEM, e malware assinado pela própria infraestrutura de code signing da Microsoft. A lição é clara — confiar cegamente no protetor é a verdadeira vulnerabilidade.
O antivírus que entrega as chaves do sistema
O Microsoft Defender roda como NT AUTHORITY\SYSTEM. Isso não é um detalhe técnico menor — é o motivo pelo qual ele é o alvo mais valioso do Windows. Quem compromete o Defender não precisa de exploit de kernel. O Defender já tem os privilégios máximos. Basta fazer ele trabalhar para você.
A CVE-2026-41091, batizada de RedSun, explora exatamente isso. O Malware Protection Engine (mpengine.dll) resolve symlinks antes de validar o caminho. Um atacante com qualquer conta local — mesmo a mais restrita — cria um symlink apontando para um arquivo privilegiado. O Defender segue o link com seus privilégios de SYSTEM e acessa o alvo. Resultado: qualquer usuário mínimo vira NT AUTHORITY\SYSTEM. CVSS 7.8, CWE-59, sem interação do usuário.
O pesquisador Nightmare Eclipse publicou os PoCs no GitHub em abril de 2026. O MSRC já havia patchado o BlueHammer (CVE-2026-33825) no Patch Tuesday de abril. Mas RedSun e UnDefend ficaram 6 semanas sem patch, com exploração ativa documentada. Seis semanas de zero-day público, ativo no wild, sem correção. Nenhuma organização deveria aceitar essa janela.
O alarme que desarma sem fazer barulho
A segunda vulnerabilidade é mais sutil e, em certos cenários, mais perigosa. A CVE-2026-45498, chamada UnDefend, causa crash do serviço MsMpEng.exe quando processa um arquivo craftado em qualquer diretório gravável. O Defender para. Sem alerta. Sem notificação. Sem ícone de warning na bandeja do sistema.
O painel mostra "atualizando" ou "última verificação: há X horas". Parece normal. Não é. O CVSS 4.0 engana — classificar como DoS um ataque que desarma o antivírus é como chamar de "arrombamento menor" o corte da linha telefônica antes do assalto. DoS no antivírus é desarmar o alarme antes do ataque real.
A Huntress documentou a intrusão em abril: atacante entrou via FortiGate VPN comprometida, executou reconhecimento básico (whoami /priv, cmdkey /list, net group), e então encadeou UnDefend e RedSun. Primeiro, o Defender crasha silenciosamente. Depois, escala para SYSTEM. Endpoint cego e comprometido. Zero detecção. Da pasta Downloads ao SYSTEM em segundos, sem que o admin saiba.
Quando a assinatura vira vetor de ataque
Se as zero-days mostram que o Defender pode ser quebrado, o Fox Tempest mostra que ele pode ser bypassado por design. A Microsoft mantém um serviço chamado Artifact Signing que emite certificados de code signing para que o Windows confie no software. Um grupo criminoso criou um serviço de assinatura de malware usando essa mesma infraestrutura.
O site signspace[.]cloud era a vitrine. Clientes criminosos faziam upload de binários. O sistema assinava com certificados emitidos pelo Microsoft Artifact Signing. Certificados de 72 horas — vida curta para limitar detecção, longa o suficiente para bypassar SmartScreen, Defender e allow-lists que confiam em binários assinados. O Windows via o selo da Microsoft e tratava o malware como software legítimo.
A infraestrutura por trás disso: 580+ contas fraudulentas usando identidades roubadas de EUA e Canadá, centenas de Azure tenants emitindo certificados independentes. Em fevereiro de 2026, VMs pré-configuradas na Cloudzy automatizavam o processo: upload do malware, receba binário assinado. Preço: 7.500 dólares em bitcoin. Alias: SamCodeSign no Telegram. Mais de 1.000 certificados fraudulentos emitidos entre maio de 2025 e maio de 2026.
Ransomware com selo de confiança
O cliente principal do Fox Tempest foi o Vanilla Tempest (Rhysida). O fluxo de ataque é revelador: um anúncio no Google redireciona buscas por "Microsoft Teams", a vítima baixa MSTeamsSetup.exe assinado com certificado Microsoft, o SmartScreen não alerta, o Windows confia, e o Oyster backdoor instala o Rhysida ransomware. Mesmo caminho com AnyDesk, PuTTY e Webex falsos.
Outros clientes incluíram Storm-0501, Storm-0501, Storm-2561 e Storm-0249. Malware distribuído: Lumma, Vidar, INC, Qilin, Akira, BlackByte. Setores atingidos: healthcare, educação, governo e financial services. A cadeia de confiança do Windows foi transformada em arma — o selo que deveria proteger virou o mecanismo que permite a execução.
A Microsoft DCU agiu em maio de 2026: seizure do signspace[.]cloud, centenas de VMs derrubadas, mais de 1.000 certificados revogados, processo no Distrito Sul de Nova York. O DCU fez test purchases de 7.500 dólares em bitcoin para documentar a operação. Mas os certificados de 72h já haviam feito seu trabalho. Milhares de máquinas infectadas, incluindo 12+ da própria Microsoft.
O modelo de ameaça que ninguém revisou
O padrão desses incidentes é o mesmo: a infraestrutura de segurança do Windows foi projetada com um modelo de ameaça que assume que o próprio ecossistema Microsoft é confiável por definição. O Defender roda como SYSTEM porque precisa de acesso total. O SmartScreen aprova binários assinados pela Microsoft. As allow-lists tratam assinaturas como proof of safety.
Mas code signing atesta identidade, não segurança. Quando a verificação de identidade pode ser fraudada em escala — como Fox Tempest provou — a assinatura vira vetor de ataque. E quando o software que deveria detectar ameaças é ele mesmo o caminho para escalação de privilégios — como RedSun provou — a arquitetura de segurança precisa de camadas independentes.
Na Tech86, nossa posição é direta: segurança por camadas não é luxo, é requisito. Um EDR independente com telemetria própria não depende do mesmo engine do Defender. Quando o Defender é cego — por crash, por zero-day, ou por assinatura fraudada — o EDR continua detectando. Monitore Event IDs 2001/2002/2003 para falhas de atualização e 4672 para escalação de privilégio. Verifique se Engine está em 1.1.26040.8+ e Platform em 4.18.26040.7+. E nunca trate um binário assinado como seguro por default.
A segurança não pode depender de um único provedor — especialmente quando esse provedor é, simultaneamente, o alvo mais atacado e a fonte de confiança que os atacantes aprendem a explorar.