Escalada de privilegios no Windows: vetores e endurecimento

A escalada de privilégios no Windows é uma das fases mais decisivas de uma intrusão real e, ao mesmo tempo, uma das mais defensáveis. Este artigo é dirigido a equipes azuis, engenheiros de detecção e administradores de sistemas que precisam entender a mecânica para poder se defender dela. Vamos descrever, em nível conceitual, como um atacante que já tem um acesso de baixos privilégios tenta se tornar SYSTEM ou administrador de domínio, qual telemetria revela essas tentativas e como endurecer um parque Windows para que os vetores mais comuns simplesmente não existam. Aqui não há cargas úteis prontas para executar: o objetivo é detecção e mitigação duradouras, não um manual de comprometimento.

O que a escalada de privilégios realmente significa

A escalada de privilégios é a transição de um contexto de segurança para outro mais poderoso no mesmo host ou domínio. Os defensores costumam dividi-la em duas famílias. A escalada vertical passa de um usuário padrão ou de baixa integridade para uma conta de altos privilégios como NT AUTHORITY\SYSTEM, um administrador local ou um administrador de domínio. A escalada horizontal move-se lateralmente para outro usuário de privilégio semelhante a fim de alcançar dados ou confiança que a conta original não tinha. A escalada quase nunca ocorre de forma isolada: situa-se entre o acesso inicial e o movimento lateral no ciclo do ataque, e é frequentemente o passo em que uma infecção menor se torna um comprometimento total. Por isso, detectar tentativas de escalada tem grande valor mesmo quando falham, pois uma tentativa fracassada revela um acesso que você não sabia que existia.

Como o Windows impõe privilégios em primeiro lugar

Para defender a fronteira é preciso saber onde ela está. O Windows atribui a cada processo um token de acesso que carrega o SID do usuário, os SIDs de grupo, um nível de integridade (Baixo, Médio, Alto, Sistema) e um conjunto de privilégios como SeDebugPrivilege, SeImpersonatePrivilege e SeBackupPrivilege. O Controle de Conta de Usuário (UAC) divide o logon de um administrador em dois tokens: um filtrado, de integridade média, para o trabalho diário, e um completo, de integridade alta, que só aparece após um pedido de elevação. A maioria das técnicas de escalada é, no fundo, uma tentativa de obter um token que o usuário nunca deveria ter, ou de executar código dentro de um processo que já o possui. Compreender tokens, níveis de integridade e privilégios é, portanto, o vocabulário comum de toda detecção e toda mitigação que se segue.

Os vetores comuns e onde eles residem

Os vetores de escalada agrupam-se em um punhado de configurações incorretas recorrentes, e nomeá-los de forma defensiva permite auditar sua ausência. As configurações incorretas de serviços são o caso clássico: um serviço que roda como SYSTEM mas cujo binário, ou cuja pasta, é gravável por usuários sem privilégios permite substituir o que o serviço executa. Relacionado está o problema do caminho de serviço sem aspas, no qual um caminho com espaços faz o Windows tentar primeiro executáveis de nível superior. Permissões fracas de serviço permitem reconfigurar diretamente o caminho do binário. Do lado do instalador, as políticas emparelhadas AlwaysInstallElevated deixam qualquer usuário instalar pacotes como SYSTEM. O abuso de tokens aproveita contas com privilégios de personificação, comum em contas de serviço web e de banco de dados. O sequestro da ordem de busca de DLL coloca uma biblioteca onde um processo privilegiado a carregará. Por fim, o roubo de credenciais da memória, do registro ou de arquivos de instalação autônoma muitas vezes permite ao atacante pular a escalada por completo. Não é preciso ferramenta de ataque para achar isso; uma auditoria de configuração encontra antes.

Detecção: a telemetria que expõe a escalada

A escalada é barulhenta se você escuta nos canais certos. Ative e encaminhe o log de segurança do Windows junto com o Sysmon e seu EDR, e centre a detecção em alguns sinais duradouros. O evento 4672 ("Privilégios especiais atribuídos ao novo logon") dispara quando uma sessão recebe privilégios sensíveis como SeDebugPrivilege; correlacione a conta e o processo pai. Os eventos 4673 e 4674 registram operações privilegiadas de serviço e de objeto. A escalada baseada em serviço aflora por meio do 7045 (um novo serviço foi instalado) e do 4697, mais o ID de evento 1 do Sysmon (criação de processo) mostrando uma cadeia pai-filho inesperada como services.exe lançando cmd.exe. Manipulação e injeção de tokens aparecem como os IDs 8 (CreateRemoteThread) e 10 (ProcessAccess) do Sysmon contra lsass.exe com máscaras de acesso suspeitas. Vetores do registro como AlwaysInstallElevated aparecem como o ID de evento 13 do Sysmon. As detecções mais fortes combinam isso: um processo de integridade média que de repente gera um filho de integridade alta, ou uma conta de serviço que obtém personificação e então lança um shell.

Construir detecções que sobrevivam a ambientes reais

IDs de evento crus geram ruído, então transforme-os em regras baseadas em comportamento. Alerte sobre transições de nível de integridade: uma árvore de processos em que um pai de integridade média produz um filho de integridade alta ou de sistema sem um evento legítimo de consentimento do UAC merece investigação. Estabeleça uma linha de base dos seus serviços legítimos e alerte quando o 7045 instalar um serviço com caminho de binário em C:\Users, C:\Windows\Temp ou outro local gravável pelo usuário. Vigie as contas com SeImpersonatePrivilege que lançam shells interativos. Mapeie cada regra às técnicas do MITRE ATT&CK sob a tática de Escalada de Privilégios (TA0004) para tornar as lacunas visíveis, e valide as regras com um exercício autorizado de equipe roxa em vez de supor que elas disparam. Alimente os alertas em um fluxo de triagem que capture o token, a cadeia de pais e o artefato modificado, pois esses três fatos costumam reconstruir toda a técnica.

Mitigação e endurecimento que removem os vetores

A melhor detecção de escalada é um vetor que não existe mais. Imponha o menor privilégio: usuários padrão nunca devem ser administradores locais, e contas de serviço devem ser Group Managed Service Accounts limitadas exatamente ao necessário. Audite e corrija as ACLs de arquivos e pastas de cada caminho de binário de serviço para que não administradores não possam gravar neles, e resolva cada caminho de serviço sem aspas. Defina ambos os valores AlwaysInstallElevated como desativados via política de grupo. Remova privilégios sensíveis como SeImpersonatePrivilege das contas que não os exigem, e isole credenciais com Credential Guard e a proteção do LSA (RunAsPPL) para dificultar o roubo em memória. Mantenha os sistemas atualizados, já que muitos exploits de escalada visam vulnerabilidades locais conhecidas. Implante controle de aplicações (WDAC ou AppLocker) para que um binário plantado não possa executar mesmo que uma ACL falhe. Por fim, monitore o abuso de carregamento de drivers, pois drivers assinados mas vulneráveis são uma ponte de escalada cada vez mais comum.

Armadilhas que enfraquecem um programa de resto bom

Vários erros recorrentes esvaziam uma defesa contra a escalada. O primeiro é registrar sem encaminhar: os eventos existem no endpoint mas nunca chegam ao SIEM, de modo que o atacante que apaga o log local elimina a única evidência. O segundo é a fadiga de alertas por eventos 4672 crus, que disparam constantemente para administradores legítimos; sem linha de base, os analistas aprendem a ignorar o que importa. O terceiro é confiar demais no UAC como fronteira de segurança — a própria Microsoft não trata o UAC padrão como tal. O quarto são as ACLs de serviço desatualizadas introduzidas por instaladores de terceiros muito depois do endurecimento inicial, razão pela qual a auditoria deve ser contínua. Por fim, as equipes muitas vezes esquecem as tarefas agendadas e as pastas de inicialização, que oferecem o mesmo padrão dos serviços e merecem o mesmo escrutínio.

Uma lista de verificação prática de endurecimento e detecção

Use isto como uma auditoria recorrente, não como um projeto único. 1) Confirme que nenhum usuário padrão é administrador local. 2) Enumere os caminhos de binários de serviço e verifique que nenhum é gravável por não administradores. 3) Resolva cada caminho de serviço sem aspas. 4) Verifique que ambos os valores AlwaysInstallElevated estão desativados. 5) Revise quais contas possuem SeImpersonatePrivilege, SeDebugPrivilege e SeBackupPrivilege, e retire o desnecessário. 6) Ative o Credential Guard e a proteção do LSA onde houver suporte. 7) Implante WDAC ou AppLocker em modo de imposição. 8) Envie os logs de Segurança, Sysmon e EDR ao SIEM e confirme a ingestão. 9) Alerte sobre saltos de integridade, caminhos 7045 suspeitos e acesso a lsass.exe. 10) Valide toda a cadeia a cada trimestre com um teste autorizado de equipe roxa.

Perguntas frequentes

Alguma vez é aceitável desativar o UAC para reduzir avisos? Não. Embora a Microsoft não classifique o UAC padrão como uma fronteira de segurança formal, ele ainda eleva o custo de muitas técnicas de escalada e fornece o evento de consentimento do qual várias detecções dependem. Reduza os avisos com o empacotamento correto de aplicações e o menor privilégio, nunca desligando o UAC.

Ainda precisamos de detecções no host se temos um EDR forte? Sim. O EDR é poderoso mas não onisciente, e somar Sysmon mais logs de segurança encaminhados dá uma fonte de evidência independente que sobrevive a um atacante que adultera o agente. A defesa em profundidade aplica-se também à sua própria visibilidade, não apenas ao caminho do atacante.

Conclusão

A escalada de privilégios no Windows parece intimidante porque tem muitas técnicas com nome, mas da cadeira do defensor ela se reduz a um pequeno conjunto de configurações incorretas evitáveis e a um pequeno conjunto de sinais de alto valor. Remova os binários de serviço graváveis, os caminhos sem aspas, os privilégios desnecessários e a política AlwaysInstallElevated, e você elimina de imediato a maior parte da exposição do parque. Encaminhe o log de segurança com Sysmon e seu EDR, alerte sobre transições de integridade e instalações de serviço suspeitas, e valide a cobertura com testes autorizados, e verá as tentativas que restarem. Entender o ataque só é útil aqui na medida em que torna a defesa concreta — e no Windows, a defesa está bem ao alcance.