Hardening de Windows 11 para Estacoes de Trabalho de Alto Risco

Uma estacao de pentester comprometida e um pesadelo regulatorio: chaves SSH de clientes, capturas de credenciais, payloads assinados e relatorios sob NDA convivem na mesma maquina. Na Basilisk OffSec, tratamos cada laptop Windows 11 como um endpoint hostil ate prova em contrario, e o endurecemos como se o operador fosse ser phishado, assaltado e auditado na mesma semana. Esta nota documenta o baseline que rodamos em producao desde marco de 2026 em 47 maquinas: ASR rules em modo block, Credential Guard com VBS reforcado, AppLocker para o perimetro de usuario e WDAC para o kernel. O resultado nao e bonito de configurar, mas reduziu de forma mensuravel a superficie que mapeamos em Bypass de AMSI e ETW para Pesquisa Defensiva: O que Blue Teams Devem Saber. Esta versao ampliada percorre toda a pilha camada por camada, com os ajustes exatos, os trade-offs e a ordem de rollout que evita que voce mesmo brique a propria frota.

O modelo de ameaca: por que o laptop do operador e a joia da coroa

Antes de tocar em um unico objeto de politica de grupo, escreva contra quem voce defende. Um laptop de seguranca ofensiva nao e um endpoint corporativo normal: ele guarda segredos de cliente descriptografados, perfis de C2 e relatorios que descrevem como invadir outras empresas. Os adversarios realistas sao tres: um operador de phishing que aterrissa um macro ou um LNK malicioso, um ladrao que arranca o dispositivo num aeroporto, e um atacante determinado que quer especificamente os dados do cliente. Cada um exige um controle distinto. Phishing se responde com controle de execucao (ASR, AppLocker, WDAC); roubo se responde com criptografia de pre-boot e vinculo ao TPM; comprometimento dirigido se responde com isolamento de credenciais e telemetria. Pular o modelo e ligar tudo de uma vez e como as equipes quebram labs de Caldera e depois, frustradas, desativam a politica inteira. Mapeie os ativos, priorize-os, e deixe esse ranking decidir qual chave voce liga primeiro.

Fundacao de hardware: TPM, Secure Boot, DMA e firmware

Todo controle de software abaixo repousa sobre hardware confiavel, entao comecamos por ai. Exigimos TPM 2.0 ativo, Secure Boot com nossas proprias chaves inscritas, protecao Kernel DMA habilitada e firmware com Intel Boot Guard ou AMD Platform Secure Boot conforme o vendor. Sem essa raiz de confianca, qualquer politica vira teatro: um ataque DMA por Thunderbolt ou um bootloader adulterado desmonta tudo em minutos. O laptop padrao e um ThinkPad P14s Gen 5 ou um Surface Laptop 7. Desabilitamos CSM legado, travamos o firmware com senha de supervisor e desligamos boot por USB e rede para a frota geral. No firmware tambem desabilitamos radios sem uso e o leitor de digital quando o modelo exige pre-boot so por PIN. Para quem quer o mesmo padrao operacional em servidores, escrevemos Hardening de Linux Servidor: CIS Benchmark Aplicado sem Quebrar Producao com a mesma filosofia.

Criptografia de disco completo: BitLocker com PIN de pre-boot

BitLocker e inegociavel e precisa estar atado ao TPM mais PIN de pre-boot, nao so ao TPM. TPM-only desbloqueia o disco automaticamente no boot, o que significa que um laptop desligado e roubado esta a um truque de cold-boot ou DMA do texto claro. Forcamos XTS-AES 256, exigimos um PIN numerico de no minimo oito digitos (via a politica de autenticacao adicional na inicializacao) e guardamos a chave de recuperacao de 48 digitos num cofre offline da equipe, nunca em conta Microsoft nem num Active Directory legivel pelo helpdesk. Tambem habilitamos BitLocker para unidades de dados fixas e removiveis, de modo que a particao de relatorios e qualquer USB de trabalho ficam cobertos. A suspensao de protecao para atualizacoes casuais de firmware fica desativada; cada desbloqueio e logado. Resultado: um dispositivo perdido e uma perda de hardware, nao uma notificacao de vazamento.

Credential Guard, VBS, Secure Launch e HVCI

A primeira camada de software e a seguranca baseada em virtualizacao. Via Group Policy tornamos obrigatorios Device Guard, Virtualization Based Security, Secure Launch e HVCI (integridade de codigo forcada pelo hipervisor). O Credential Guard move os hashes NTLM e os tickets Kerberos para um processo isolado em VTL1 que o SO normal nao consegue ler, de modo que um ponto de apoio na sessao de usuario nao pode simplesmente raspar credenciais de dominio da memoria. O HVCI exige que apenas codigo assinado e verificado rode no kernel, fechando a porta para rootkits sem assinatura e muitas cadeias BYOVD. O Secure Launch usa o DRTM da CPU para restabelecer confianca depois do firmware, encolhendo a janela de boot inicial. Ha um custo real: o HVCI bloqueia alguns drivers antigos e adiciona alguns pontos de overhead em builds pesados, medido com nosso pipeline de build do Sliver custom. Esse custo compra uma sessao de operador que vaza muito menos quando inevitavelmente e cutucada.

Protecao do LSASS: RunAsPPL e auditoria de acesso

Mesmo com Credential Guard, o LSASS continua alvo de dumping por handles, entao o rodamos como Protected Process Light. Setamos RunAsPPL=1 em HKLM\SYSTEM\CurrentControlSet\Control\Lsa (variante travada por UEFI onde suportada) e ligamos a auditoria de acesso ao LSASS. Em testes internos isso quebrou mimikatz convencional, o abuso de MiniDump via comsvcs.dll e varios truques de duplicacao de handle sem precisar de EDR, e o LSA Protection bloqueou toda tentativa de injecao que reproduzimos a partir de Persistencia em Windows: 10 Tecnicas Documentadas e suas Contramedidas. O controle complementar e uma regra de deteccao sobre acesso a handles de processo ao lsass.exe com mascara de acesso desejada 0x1010 ou 0x1410, o sinal delator de uma tentativa de dump. Custo: aproximadamente quatro por cento de overhead de CPU em compilacoes Rust pesadas, medido com nosso pipeline do Sliver custom. Preco barato para o caminho de roubo de credencial mais abusado no Windows.

Regras de Attack Surface Reduction em modo block

ASR vem em seguida e e exatamente onde a maioria das equipes perde a coragem. Habilitamos as dezesseis regras em block, nao em audit. Sim, isso quebra child processes do Office, execucao de scripts ofuscados, processos gerados por WMI e executaveis de USB nao confiavel. Mantemos uma OU separada chamada "OffSec-Tools" onde algumas regras ficam em audit para a maquina de laboratorio do pesquisador que precisa rodar Caldera, como descrito em Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo. Para o resto da frota, a regra D4F940AB-401B-4EFC-AADC-AD5F3C50688A (bloquear child processes do Office) sozinha derrubou 73 por cento dos initial access que simulamos em Initial Access Simulado: Macros, LNK e ISO em Lab Windows 11 Isolado. Combine-a com bloquear roubo de credenciais do LSASS, conteudo executavel de e-mail e chamadas Win32 de macros do Office para o maior retorno por regra.

AppLocker para o perimetro de usuario

AppLocker e WDAC vivem em camadas distintas e voce quer os dois. O AppLocker governa user-mode com allowlists por publisher e por path e e ideal para barrar o ZIP suspeito que o usuario baixou em Downloads ou um script sob um perfil de usuario. Negamos por padrao a execucao a partir de locais gravaveis (Downloads, Temp, AppData) e permitimos apenas binarios assinados mais um path de ferramentas curado sob um diretorio de propriedade do admin. As regras cobrem EXE, DLL, MSI, Script e apps empacotados; as regras de DLL estao ativas apesar do custo porque o side-loading de DLL e uma tecnica favorita de loaders. O AppLocker e aplicado via o servico Application Identity e auditado primeiro: duas semanas em "somente auditoria", colhemos os eventos 8003 e 8004, e entao passamos para enforce. Nao e uma fronteira dura sozinho, mas como peneira externa na frente do WDAC ele remove uma enorme classe de lixo lancado pelo usuario.

WDAC para a camada de kernel e drivers

O WDAC (Windows Defender Application Control) e a verdadeira fronteira de integridade de codigo e cobre kernel e drivers via uma politica assinada atada ao nosso certificado EV, com as Microsoft Recommended Driver Block Rules importadas em janeiro de 2026. Geramos a politica base com New-CIPolicy, rodamos em audit por 30 dias, coletamos os event IDs 3076 e 3077, refinamos e so entao promovemos para enforce. O ganho: drivers vulneraveis catalogados no loldrivers.io, incluindo os usados nas rotinas de evasao que cobrimos em Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao, simplesmente nao carregam. So executam binarios assinados pela Microsoft, pelo OEM (Lenovo, Microsoft Surface) ou que batem com nossos hashes internos. Fazemos deploy da politica como arquivo assinado e travado por UEFI, de modo que um atacante com admin nao consiga troca-la em silencio, e alertamos em qualquer evento de modificacao de politica como sinal de alta severidade.

Microsoft Defender como ultima camada e sua telemetria

O Defender entra por ultimo com Tamper Protection ligada, Cloud Block Level em alto, PUA em block, Network Protection ligado e Controlled Folder Access cobrindo Documentos, Desktop e o diretorio de relatorios. O ponto nao e que o Defender pegue tudo; e que cada camada acima ja estreitou o campo, entao o Defender agora e um sensor de alto sinal em vez de um porteiro barulhento. Enviamos os eventos para o pipeline Sigma+Elastic descrito em Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao, com foco em modificacao de politica WDAC, criacao de servico via sc.exe, persistencia por tarefas agendadas e acesso a handles do LSASS com mascara 0x1010. Em 90 dias em 47 estacoes registramos zero comprometimentos confirmados e doze alertas de alto sinal, dois deles tentativas reais de drive-by durante engagements de bug bounty. Telemetria sem escala de revisao e decoracao, entao cada classe de alerta tem um owner nomeado e um runbook.

Metodologia de rollout e governanca de exclusoes

O maior modo de falha e ligar todas as chaves de uma vez, quebrar alguem no meio de um engagement e ter a politica inteira desativada com raiva antes do almoco. Nao faca isso. Rode 30 dias em audit, exporte os logs para um SIEM, ajuste o conjunto minimo viavel de exclusoes e so entao mova para block. Cada exclusao recebe um ticket de Jira, um owner nomeado e uma data de revisao trimestral, porque hardening que ninguem revisa apodrece em seis meses quando chegam ferramentas e versoes de driver novas. Versione as politicas como codigo num repo git, assine-as na CI e faca deploy via Intune ou seu gerenciador de configuracao para que o baseline seja reproduzivel e diffavel. Trate a OU OffSec-Tools como uma excecao documentada e monitorada, nao como uma porta dos fundos permanente, e re-baseline-a a cada trimestre contra o que os pesquisadores de fato ainda precisam.

FAQ: isso quebra o tooling diario de pentest?

Na maioria das vezes nao, e onde quebra a quebra e intencional e delimitada. WDAC em enforce bloqueia tooling custom sem assinatura, por isso o lab do pesquisador vive na propria OU com politica relaxada e sem dados de cliente. Para a frota de producao assinamos nossos binarios internos e adicionamos seus hashes a politica WDAC, de modo que ferramentas caseiras em Rust e Go rodam enquanto executaveis sem assinatura aleatorios nao. ASR em block impede que o Office lance cmd.exe ou PowerShell, o que quase nunca acontece em trabalho legitimo de operador; os poucos templates de relatorio pesados em macros foram migrados para fora do VBA. Se uma ferramenta realmente precisa de uma excecao, ela passa pelo processo de exclusao com ticket em vez de um relaxamento geral de politica, de modo que o raio de impacto de cada permissao continua pequeno e auditavel.

FAQ: como comeco do zero sem downtime?

Ative controles em ordem de dependencia para que cada passo seja valioso e reversivel por si so. A sequencia que recomendamos e: primeiro BitLocker com PIN de pre-boot, depois Credential Guard e VBS, depois LSA PPL, depois ASR em audit seguido de block, depois AppLocker em audit seguido de enforce, depois WDAC em audit seguido de enforce. Cada estagio roda pelo menos uma semana com logs fluindo para o SIEM antes que o proximo entre, de modo que uma regressao e contrastada contra uma variavel e nao dez. Mantenha um rollback documentado para cada GPO e um admin local de emergencia guardado offline. Ninguem deveria conseguir apontar para uma unica mudanca e dizer "nao sabemos se foi aquilo que quebrou", porque voce mudou exatamente uma coisa por vez.

Conclusao: um baseline que sobrevive ao contato

Hardening de estacoes de alto risco nao e um projeto heroico de um dia; e um baseline em camadas que precisa sobreviver a engagements reais, cenarios de roubo reais e auditorias reais. Raiz de confianca em hardware, BitLocker com PIN, Credential Guard, LSA PPL, ASR em block, AppLocker, WDAC e um sensor Defender alimentando um pipeline monitorado transformam juntos o laptop do operador de alvo mole em um lugar genuinamente hostil para aterrissar. A ordem importa tanto quanto os ajustes: audit antes de block, uma variavel por vez, cada excecao com ticket e revisada. Faca nessa sequencia, mantenha as politicas em git, e voce rodara operacoes ofensivas em maquinas que de fato consegue defender, entregar a um auditor e perder num aeroporto sem escrever uma notificacao de vazamento.