Experimento controlado mostra que modelo de pesos abertos executado localmente reescreveu utilitário de dump de memória do LSASS e obteve zero detecções em duas plataformas EDR, evidenciando queda na barreira técnica para desenvolvimento de ferramentas ofensivas customizadas
| Componente | Extração de memória do processo LSASS em Windows (MITRE ATT&CK T1003.001), com utilitário modificado por modelos de linguagem locais |
| Vetor | Modelo de pesos abertos sem restrições de segurança, executado localmente em hardware de consumo, recebeu pedido de tornar executável de dump de LSASS mais furtivo; exige acesso administrativo ou SYSTEM no host-alvo para execução da ferramenta |
| Impacto | Variante revisada gerou zero detecções em duas plataformas EDR de laboratório após alterações de spawn de processos, máscaras de acesso, atrasos aleatórios, nome de arquivo e limpeza de strings; escopo limitado e não comprova bypass universal |
| Prioridade | Tratar EDR como camada única insuficiente: habilitar regra de redução de superfície de ataque contra roubo de credenciais do LSASS com proteção contra adulteração, executar LSASS como Protected Process Light, ativar Credential Guard, restringir RDP, desabilitar WDigest e monitorar acessos anômalos ao LSASS |
Uma pesquisa divulgada no fim de setembro de 2026 demonstrou, em ambiente de laboratório controlado, que um modelo de linguagem de pesos abertos e sem restrições de segurança, executado localmente, conseguiu modificar um utilitário de extração de credenciais do Windows até que ele deixasse de ser detectado por duas plataformas de Endpoint Detection and Response (EDR). O alvo do experimento foi o processo LSASS (Local Security Authority Subsystem Service), cuja memória pode conter material de autenticação reutilizável por atacantes que já obtiveram acesso administrativo a um host, incluindo hashes de senhas e tickets úteis para movimentação lateral dentro do domínio.
O ponto central da descoberta não é uma nova vulnerabilidade, mas a queda na barreira de entrada para produzir código ofensivo customizado. A sub-técnica T1003.001 do MITRE ATT&CK, que cataloga o dump de memória do LSASS, é uma das atividades pós-comprometimento mais monitoradas por soluções de endpoint, exatamente porque depende de artefatos conhecidos: linhagem suspeita de processos, requisições de handle com privilégio elevado contra o LSASS, criação de arquivos de dump e strings características em binários. O experimento mostra que modelos locais sem salvaguardas podem reescrever esses artefatos de forma iterativa, sem envio de prompts ou código-fonte para serviços hospedados, reduzindo o tempo e o nível de especialização necessários para gerar variantes específicas por ambiente.
É importante delimitar o escopo: os fabricantes das duas soluções EDR utilizadas no teste não foram identificados, os detalhes de configuração não foram publicados e o sucesso contra dois produtos de laboratório não estabelece capacidade de bypass universal. Ainda assim, o resultado é um alerta concreto para equipes defensivas sobre a necessidade de adotar defesa em profundimento na proteção de credenciais, em vez de confiar exclusivamente na detecção comportamental de endpoint.
O pesquisador iniciou o projeto com um parâmetro deliberadamente desafiador: gerar um executável capaz de realizar o dump do LSASS sem detecção por EDRs modernos, com o mínimo de intervenção humana. As primeiras tentativas usaram modelos comerciais hospedados Claude Opus 5, Opus 4.8 e Sonnet 5, que recusaram imediatamente os pedidos, mesmo com o pesquisador enquadrado em programa de verificação cibernética do fornecedor. A recusa consistente dos modelos comerciais alinhados ilustra por que a pesquisa migrou para modelos de pesos abertos.
Em seguida, foi testado o modelo aberto DeepSeek v4 Flash 0731. Após alguns prompts, o modelo produziu um executável funcional que aceitava um identificador de processo, criava um clone suspenso do alvo por meio de reflexão, gerava um minidump em memória, cifrava o conteúdo com XOR e gravava a saída cifrada em disco. O dump foi validado com a ferramenta pypykatz, confirmando que o arquivo era analisável e continha material de credenciais utilizável. O binário inicial, contudo, ainda disparava detecção nas plataformas EDR do laboratório; quando o pesquisador pediu melhorias de furtividade, o DeepSeek acionou uma salvaguarda e interrompeu a colaboração.
A etapa decisiva ocorreu com um modelo Qwen 3.8 27B modificado pela comunidade para operar sem restrições, executado localmente em um equipamento de quebra de senhas com duas placas Nvidia RTX 4090. Com um único pedido para tornar o executável mais furtivo, o modelo retornou uma versão revisada que não gerou detecções em nenhuma das duas plataformas EDR disponíveis. A revisão de código mostrou que o modelo alterou o comportamento de criação de processos, reduziu as máscaras de acesso solicitadas contra o processo-alvo, inseriu atrasos aleatórios durante a construção do minidump, alterou nome e caminho do arquivo de saída e removeu strings embutidas do binário.
Cada uma dessas modificações ataca diretamente um pilar de detecção conhecido. Ferramentas de dump tradicionais são identificadas pela correlação entre linhagem de processos suspeita, requisições de handle de alto privilégio contra o LSASS, strings conhecidas no binário, criação do arquivo de dump e comportamento temporal previsível. Ao fragmentar e randomizar esses artefatos, o código gerado por IA escapa de assinaturas e heurísticas que dependem de padrões estáticos ou de sequências rígidas de eventos.
A superfície de risco real está em ambientes Windows onde o LSASS opera sem proteções adicionais e onde um atacante já possui privilégios administrativos ou de SYSTEM. O dump de memória do LSASS é uma etapa pós-comprometimento: pressupõe acesso inicial já conquistado e serve para colher credenciais que viabilizam autenticação em outros sistemas da rede. Portanto, o cenário de risco é o de movimentação lateral facilitada por material de autenticação reutilizado, e não uma falha de acesso remoto explorável diretamente.
O segundo plano de exposição é organizacional e diz respeito à disseminação de modelos locais sem salvaguardas. Hardware de consumo, como placas gráficas de uso doméstico, é suficiente para executar modelos capazes de iterar sobre código ofensivo conhecido, sem logs de provedor de nuvem, sem telemetria de prompts e sem qualquer ponto de auditoria externo. Isso reduz tanto o rastro forense do desenvolvimento quanto a expertise necessária para produzir variantes ajustadas a controles específicos de cada ambiente.
- Hosts Windows com LSASS sem execução como Protected Process Light e sem Credential Guard ativo
- Ambientes com administração via RDP permissiva e credenciais em cache pelo WDigest
- Contas com direitos de administrador local abundantes e ausência de separação de contas privilegiadas
- Redes que dependem exclusivamente de EDR para detectar T1003.001, sem camadas complementares de proteção de credenciais
A detecção precisa considerar que os artefatos clássicos do dump de LSASS podem ser deliberadamente deformados. Regras que dependem de strings de ferramentas conhecidas, nomes de arquivo fixos ou sequências temporais rígidas perdem eficácia diante de variantes geradas por IA. A telemetria de maior valor é a que observa comportamento estrutural difícil de disfarçar: qualquer processo que não seja o próprio LSASS ou um mecanismo legítimo do sistema solicitando handles de leitura de memória contra o LSASS continua sendo sinal central, independentemente da máscara exata solicitada.
A documentação pública de referência sobre o tema reforça abordagens tool-agnostic: monitoramento de requisições de handle contra o LSASS com máscaras de acesso frequentemente usadas por utilitários de dump, e a detecção por sequência de acesso anormal a processo seguido de atividade de dump de memória ou criação de arquivo. Como a variante do experimento reduziu máscaras e randomizou atrasos, os analistas devem ampliar a janela de correlação temporal e priorizar eventos de acesso a processo privilegiado, em vez de depender de janelas curtas e encadeamento imediato de eventos.
- Eventos de requisição de handle contra o processo LSASS por processos não assinados ou de linhagem incomum (Event ID 4656/4663 com Object Type Process)
- Criação de processos em estado suspenso e clonagem de processo por reflexão a partir de binários não reconhecidos
- Gravação de arquivos cifrados com conteúdo opaco por processos com privilégio SYSTEM, especialmente fora de diretórios padrão
- Acessos ao LSASS que ocorram em horários atípicos ou a partir de sessões de administração remota iniciadas por RDP
- Correlação estendida no tempo entre acesso privilegiado a processo e posterior movimentação de autenticação com credenciais colhidas
A resposta defensiva recomendada pela pesquisa parte do princípio de que o EDR é uma camada, não uma garantia. A primeira ordem de ação é blindar o próprio LSASS: habilitar a regra de redução de superfície de ataque contra roubo de credenciais do LSASS com proteção contra adulteração ativada, executar o LSASS como Protected Process Light e implantar Credential Guard, que isola material de autenticação em um ambiente virtualizado seguro fora do alcance direto de processos administrativos comuns.
Na sequência, reduzir a utilidade do material colhido: desabilitar o cache de credenciais via WDigest, restringir administração por RDP, minimizar direitos de administrador local, separar contas privilegiadas das contas de uso diário e exigir credenciais únicas por host e por função. Mesmo que um dump seja bem-sucedido, credenciais isoladas e protegidas por Credential Guard reduzem drasticamente o valor do material extraído e contêm a movimentação lateral.
Por fim, operacionalizar a contenção: monitorar acessos incomuns ao LSASS como prioridade de triagem e isolar rapidamente hosts que apresentem comportamento de extração de credenciais, tratando o evento como indicador de comprometimento em andamento e não como falso positivo isolado. A pesquisa também sugere atenção crescente ao ecossistema de modelos locais sem restrições, uma vez que o desenvolvimento de ferramentas ofensivas customizadas fica mais rápido, mais barato e sem trilha auditável em serviços hospedados.
- Habilitar a regra ASR de proteção contra roubo de credenciais do LSASS com proteção contra adulteração
- Executar LSASS como Protected Process Light e implantar Credential Guard
- Desabilitar WDigest e restringir administração remota via RDP
- Minimizar administradores locais, separar contas privilegiadas e adotar credenciais únicas
- Configurar alerta prioritário para acesso anômalo ao LSASS e isolamento imediato do host afetado
0 Comentários