Ataque abaixo do sistema operacional: proteger BIOS, UEFI e firmware

A camada que o antivírus não enxerga

Toda estratégia de segurança corporativa parte de uma suposição silenciosa: a de que o sistema operacional é confiável. O antivírus roda dentro do Windows, o EDR roda dentro do Windows, o agente de inventário roda dentro do Windows. Se o código que carrega o Windows já estiver comprometido antes do primeiro processo subir, todas essas ferramentas passam a operar dentro de um ambiente que mente para elas. É exatamente esse o objetivo de um ataque a firmware.

Entre o momento em que a máquina é ligada e o momento em que a tela de login aparece, existe uma sequência de execução que quase nenhuma empresa monitora. O firmware UEFI inicializa o hardware, valida dispositivos, carrega drivers de inicialização e entrega o controle ao bootloader. São milhões de linhas de código rodando com privilégio máximo, sem nenhuma das proteções que o sistema operacional oferece. Um invasor que consegue escrever nessa camada não precisa mais se preocupar com senha de administrador, com política de grupo ou com detecção comportamental.

O agravante é a persistência. Uma infecção comum morre quando a máquina é formatada. Um bootkit gravado na memória flash SPI da placa-mãe sobrevive à formatação, sobrevive à troca do disco e sobrevive à reinstalação do sistema operacional. A equipe de TI reinstala tudo, entrega o notebook de volta ao usuário e considera o incidente encerrado — enquanto o implante continua ativo, esperando o próximo boot para se reinjetar na memória.

Como funciona um bootkit UEFI na prática

O caminho mais comum não é mágico: começa com acesso administrativo ao sistema operacional. O invasor entra por phishing, por credencial vazada ou por uma vulnerabilidade explorada, escala privilégio até SYSTEM e então busca uma porta de entrada para o firmware. Essa porta costuma ser um driver assinado com falha de validação — o chamado ataque BYOVD, "bring your own vulnerable driver" — ou uma vulnerabilidade no próprio UEFI que permite escrita na região SPI quando as travas de proteção não foram configuradas pelo fabricante.

A partir daí, o implante se instala em um ponto que será executado antes de qualquer defesa. Famílias já documentadas publicamente, como LoJax, MosaicRegressor, ESPecter, MoonBounce, CosmicStrand e BlackLotus, seguem variações desse roteiro. O que mudou nos últimos anos foi a acessibilidade: o que antes era ferramenta de operação estatal passou a ser vendido em fóruns criminosos como produto, com preço, atualização e suporte.

Uma vez ativo, o implante costuma fazer três coisas: desabilitar ou enganar mecanismos de integridade do sistema operacional, gravar um payload no disco a cada inicialização e abrir um canal de comunicação com o servidor do atacante. Para o time de segurança, o sintoma visível é frustrante — o malware "volta sozinho" depois de cada limpeza, sem explicação aparente na cadeia de eventos do endpoint.

Regra prática: quando uma infecção reaparece após formatação completa e troca de disco, o problema não está no sistema operacional. Está abaixo dele.

Secure Boot: por que ligado não significa protegido

O Secure Boot existe justamente para quebrar essa cadeia. Ele valida a assinatura digital de cada componente carregado durante o boot e recusa o que não estiver assinado por uma autoridade confiável. É um mecanismo sólido em conceito. O problema está em como ele é operado no dia a dia das empresas.

O primeiro furo é o mais banal: Secure Boot desligado. Isso acontece com frequência em máquinas migradas de BIOS legada, em estações que rodam software antigo que exigia a desativação, em servidores instalados às pressas e em equipamentos configurados por terceiros. Ninguém volta para reativar. O segundo furo é o modo Setup — quando as chaves de plataforma foram apagadas e o firmware aceita qualquer chave nova, o Secure Boot fica tecnicamente habilitado e funcionalmente inútil.

O terceiro furo é o mais sofisticado: bootloaders legítimos e assinados que contêm vulnerabilidades. Como já estão assinados por uma autoridade aceita, o Secure Boot os aprova sem hesitar. O invasor carrega uma versão antiga e vulnerável de um componente válido e explora a falha dentro de um contexto autorizado. É por isso que existem listas de revogação — a DBX no UEFI e a política de revogação da Microsoft — e é por isso que essas listas precisam ser atualizadas, o que quase nunca acontece de forma sistemática.

Uma auditoria mínima de Secure Boot em uma frota deveria responder a quatro perguntas objetivas:

• Quantas máquinas têm Secure Boot habilitado e em modo User (não Setup)?
• Quantas ainda estão em BIOS legada em vez de UEFI nativo?
• A revogação DBX está atualizada em todas elas?
• Existe senha de supervisor no firmware, impedindo que o usuário simplesmente desligue a proteção pelo menu de boot?

Esse último ponto merece destaque. De nada adianta uma política impecável de Secure Boot se qualquer pessoa com acesso físico pode apertar F2, desabilitar tudo e dar boot por um pendrive. Senha de firmware e controle de ordem de boot são parte da mesma defesa, não itens separados.

Atualização de BIOS na frota: o processo que ninguém tem

Correções de firmware existem. Fabricantes publicam atualizações de BIOS e UEFI corrigindo vulnerabilidades de escalonamento de privilégio, falhas em SMM e problemas de validação de assinatura. O que praticamente não existe nas empresas é um processo para aplicá-las. Enquanto o patch de sistema operacional roda automatizado e auditado, o firmware costuma ser atualizado apenas quando há um defeito de hardware evidente — ou nunca.

Os motivos são compreensíveis. Atualizar BIOS envolve reinicialização, envolve risco percebido de "brickar" o equipamento, envolve modelos heterogêneos com ferramentas diferentes por fabricante e envolve máquinas que precisam estar ligadas e com bateria em nível seguro. É um trabalho chato, distribuído e de retorno invisível. Por isso ele é adiado indefinidamente até virar um problema de segurança.

A saída é tratar firmware como qualquer outro item de patch management, com inventário, janela e evidência. Na prática, isso significa montar uma rotina em etapas:

1. Inventariar versões — levantar fabricante, modelo e versão de BIOS de cada equipamento da frota, incluindo servidores e o firmware de controladoras e placas de rede.
2. Comparar com o baseline do fabricante — identificar o que está desatualizado e classificar por criticidade das correções pendentes.
3. Usar as ferramentas nativas de cada fabricante — Dell Command Update, HP Image Assistant, Lenovo Thin Installer e equivalentes permitem atualização silenciosa e agendada, com muito menos risco do que o método manual por pendrive.
4. Testar em um grupo piloto — validar em um pequeno conjunto representativo antes de liberar para toda a base.
5. Aplicar em ondas com janela definida — priorizando notebooks de diretoria, máquinas com acesso a dados sensíveis e servidores expostos.
6. Registrar evidência — versão antes, versão depois, data e responsável, para que a próxima auditoria não comece do zero.

Servidores merecem atenção separada. Firmware de BMC, iDRAC, iLO e controladoras RAID roda fora do sistema operacional e frequentemente tem interface de rede própria. Uma controladora de gerenciamento desatualizada e acessível na rede corporativa é um dos caminhos mais diretos para comprometimento total de um ambiente — e não aparece em nenhum relatório de antivírus.

O que dá para monitorar e detectar

Detectar comprometimento de firmware é difícil, mas não impossível. O ponto de partida é habilitar e usar o que o hardware moderno já oferece. O TPM registra medições de cada estágio do boot nos PCRs, e essas medições podem ser validadas remotamente por atestação. Quando o valor muda sem que tenha havido uma atualização legítima de firmware, isso é um sinal que merece investigação.

Em ambientes Windows, recursos como Secure Launch, integridade de memória e proteção baseada em virtualização elevam bastante o custo do ataque, ao isolar componentes críticos do restante do sistema. Não eliminam o risco na camada de firmware, mas dificultam a etapa de escalonamento que precede a gravação no SPI. Plataformas de EDR mais recentes também passaram a incluir varredura de firmware e verificação de configuração UEFI, o que traz parte desse território para dentro do console já usado pela equipe.

Além da tecnologia, há decisões de processo que reduzem drasticamente a superfície. Bloquear drivers vulneráveis conhecidos corta o vetor BYOVD mais comum. Restringir privilégio administrativo local limita a escalada necessária para chegar ao firmware. Definir criptografia de disco com TPM garante que uma alteração no ambiente de boot resulte em pedido de chave de recuperação, transformando um comprometimento silencioso em um evento visível.

Se o disco está criptografado com selamento no TPM, uma alteração inesperada na cadeia de boot vira um pedido de chave de recuperação. Esse "incômodo" é, na verdade, o seu alarme.

Por fim, é preciso ter um plano para o pior cenário. Se houver suspeita fundamentada de implante em firmware, a resposta correta não é formatar: é isolar o equipamento da rede, preservar evidência, aplicar reflash do firmware a partir de imagem oficial do fabricante — quando o modelo permite — e, dependendo da criticidade dos dados envolvidos, considerar a substituição do hardware. Trocar uma placa-mãe é caro; manter um implante persistente em uma máquina com acesso a dados de clientes é mais caro ainda.

Como a Duk trata a camada abaixo do sistema operacional

Segurança de firmware não é um produto que se compra e instala. É disciplina operacional: inventário sempre atualizado, baseline definido, janela de manutenção respeitada e evidência registrada. É exatamente o tipo de trabalho que se perde em equipes internas sobrecarregadas com chamados do dia a dia — e é onde um parceiro de TI faz diferença concreta.

Na Duk Informática & Cloud, o controle de firmware entra na mesma esteira de gestão dos demais ativos: mapeamos fabricante, modelo e versão de BIOS de toda a frota, verificamos estado real de Secure Boot e TPM máquina a máquina, definimos o baseline por modelo e executamos as atualizações em ondas, com piloto, janela combinada e relatório de antes e depois. O mesmo tratamento vale para servidores, controladoras de gerenciamento e equipamentos de rede.

São mais de 18 anos de experiência e mais de 550 empresas atendidas, com a condição de Microsoft Gold Partner sustentando o trabalho nas plataformas Windows, Microsoft 365 e Azure, além de data center próprio em Alphaville e suporte 24/7 com SLA definido em contrato. Isso permite tratar firmware como parte da rotina de segurança, e não como uma emergência descoberta durante um incidente.

Se a sua empresa não sabe hoje quantas máquinas estão com Secure Boot desabilitado ou há quanto tempo a BIOS não é atualizada, esse é um bom ponto de partida para uma conversa. O levantamento inicial costuma revelar rapidamente onde estão os riscos mais evidentes — e, na maioria dos casos, a correção é bem menos trabalhosa do que a percepção inicial sugere.