Técnica abusa do Subsistema do Windows para Linux, de processos Pico e de lacunas de monitoramento para executar binários Linux e Windows fora da visibilidade de produtos de segurança não adaptados ao WSL.
| Componente | Windows 10 com Windows Subsystem for Linux, processos Pico, drivers lxss.sys e lxcore.sys, utilitários de instalação do WSL e ambiente Linux baseado em Ubuntu 16.04. |
| Vetor | Malware com privilégios administrativos locais pode ativar temporariamente pré-condições do WSL, preparar o sistema de arquivos Linux e executar cargas ELF ou EXE por meio de uma cadeia que passa pelo ambiente Linux. |
| Impacto | Cargas maliciosas podem ficar fora da visibilidade de antivírus, ferramentas de inspeção, depuração e antirransomware que não monitoram processos Pico, chamadas traduzidas pelo WSL e execução originada do ambiente Linux. |
| Prioridade | Inventariar hosts Windows 10 com WSL habilitado, monitorar ativação de recursos e mudanças em chaves de modo desenvolvedor, exigir telemetria de processos Pico e validar se os controles de endpoint inspecionam execução Linux no Windows. |
| Artefatos | Bash.exe, LxRun.exe, lxss.sys, lxcore.sys, diretório oculto em %APPDATA%, arquivo lxss.tar.gz, montagem automática de partições NTFS em /mnt. |
| Limite | A técnica descrita não depende de uma falha lógica no desenho do WSL; o risco central está na ausência de cobertura de segurança para uma arquitetura híbrida recém-adotada no Windows. |
Bashware é uma técnica de evasão que demonstra como malware existente pode se beneficiar do Windows Subsystem for Linux para reduzir a visibilidade sobre sua execução em Windows 10. O ponto central não é uma família específica de malware, nem uma exploração remota isolada, mas o uso de uma camada legítima do sistema operacional para deslocar a execução para um modelo que muitos produtos de segurança ainda não inspecionavam adequadamente em 2017. O WSL permite que binários Linux do tipo ELF sejam executados nativamente no Windows sem uma máquina virtual tradicional. Essa capacidade cria uma superfície híbrida: processos, chamadas de sistema e arquivos atravessam fronteiras entre semânticas Linux e componentes do núcleo do Windows.
A técnica parte de uma diferença importante entre processos tradicionais do Windows e processos Pico. Processos Pico foram introduzidos para dar suporte à execução de binários Linux dentro do Windows e não carregam vários elementos esperados em processos NT convencionais, como estruturas comuns de ambiente e bibliotecas de modo usuário associadas ao ecossistema Win32. Mesmo com essa aparência mínima, eles continuam capazes de executar operações relevantes no sistema. Quando ferramentas de proteção observam apenas padrões clássicos de processos Windows, criação de processos Win32, chamadas de API usuais ou artefatos esperados de executáveis PE, uma carga executada por essa via pode escapar de controles que não foram projetados para essa combinação.
O impacto defensivo é concreto porque a cadeia descrita permite que cargas ELF sejam executadas diretamente pelo ambiente Linux e que cargas EXE sejam encapsuladas por uma camada de compatibilidade como Wine. Nessa segunda situação, chamadas esperadas de um programa Windows podem ser traduzidas para chamadas POSIX e depois reconvertidas pelo provedor Pico, fazendo com que o componente do WSL apareça como parte relevante da execução. Isso não transforma o WSL em malware por si só, mas cria uma zona de baixa visibilidade quando a solução de segurança não correlaciona criação de processos, ativação do recurso, alterações de configuração, montagem de NTFS e atividade resultante no sistema Windows.
O fluxo começa com a verificação de disponibilidade do WSL no host Windows 10. A técnica observa a presença ou o estado de componentes como lxss.sys e lxcore.sys, responsáveis por sustentar a compatibilidade entre chamadas Linux e o núcleo do Windows. Se o recurso não estiver ativo, a cadeia descrita tenta habilitar os componentes por meio de mecanismos legítimos de gerenciamento do sistema, com execução silenciosa e sem uma interação visível para o usuário. Essa etapa exige condição local relevante: a alteração de recursos e o acionamento do modo necessário dependem de privilégio administrativo ou de execução com token que permita modificar configurações protegidas.
Em versões iniciais do WSL, o modo desenvolvedor era uma pré-condição para o funcionamento. A técnica se aproveita de duas chaves de registro em HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock: AllowAllTrustedApps e AllowDevelopmentWithoutDevLicense. O comportamento descrito consiste em ativar esses valores somente pelo tempo necessário para prosseguir e depois retornar os valores ao estado anterior. Para a defesa, isso é relevante porque uma auditoria feita muito depois da execução pode não encontrar o estado final alterado, enquanto logs de modificação de registro e eventos de habilitação de recurso podem conter a evidência transitória.
Após preparar a capacidade do WSL, a técnica instala ou prepara o sistema de arquivos Linux usado pelo ambiente. O utilitário LxRun.exe é citado como responsável por baixar e extrair o sistema de arquivos, com Ubuntu 16.04 como base Linux observada. O arquivo compactado lxss.tar.gz é salvo em pasta oculta sob %APPDATA% antes da extração. A pesquisa também descreve uma condição de corrida durante essa fase: se um invasor conseguir trocar o arquivo entre o download e a extração, a instalação poderia aceitar um sistema de arquivos Linux modificado. O sinal usado para identificar a janela de troca seria a gravação de um hash SHA256, que no fluxo descrito funcionaria mais como marcador temporal do que como validação efetiva da autenticidade antes da extração.
Com o ambiente Linux funcional, a técnica passa a executar cargas dentro do WSL. Cargas ELF podem rodar de forma nativa no contexto Linux. Para cargas EXE, a cadeia usa Wine como camada de compatibilidade, convertendo chamadas de API Windows para semântica POSIX, que depois são tratadas pelo WSL e traduzidas de volta para chamadas NT. O efeito prático é deslocar a execução observável para componentes que ferramentas tradicionais podem interpretar como parte do subsistema, enquanto o comportamento malicioso ocorre por uma rota não coberta por inspeções convencionais. A técnica também se beneficia do fato de as partições NTFS serem montadas automaticamente em /mnt, permitindo leitura, escrita e execução sobre áreas do Windows a partir do ambiente Linux, conforme permissões do processo que iniciou a sessão.
A superfície afetada envolve computadores com Windows 10 capazes de executar WSL, especialmente no período em que o recurso saía do estado beta e se tornava componente suportado. A exposição não significa que todo host Windows 10 esteja comprometido, mas que a combinação de WSL disponível, privilégio local suficiente, lacunas de monitoramento e execução de uma carga maliciosa cria uma rota de evasão plausível. O contexto menciona que a técnica poderia alcançar o universo de máquinas Windows 10 em escala global, mas a condição operacional depende de habilitação do recurso, preparação do ambiente e execução local com permissões adequadas.
O risco aumenta em estáções de desenvolvimento, máquinas administrativas, ambientes de engenharia e endpoints em que o uso de WSL é aceito como parte do trabalho. Nesses casos, a presença de Bash.exe, sistemas de arquivos Linux e montagem de volumes Windows pode ser normal, o que reduz a qualidade de alertas baseados somente em existência do recurso. A defesa precisa distinguir uso legítimo de padrões anômalos: habilitação repentina do WSL, instalação não planejada de ambiente Linux, manipulação temporária de chaves de modo desenvolvedor, execução de Wine sem justificativa operacional e acesso incomum a diretórios sensíveis do Windows via /mnt.
A técnica não deve ser tratada como falha genérica de exfiltração ou comprometimento de dados. O impacto confirmado é evasão de monitoramento e execução de cargas em uma rota híbrida. Qualquer consequência adicional, como roubo de credenciais, criptografia de arquivos ou coleta de informações, dependeria da carga maliciosa executada dentro dessa cadeia. Por isso, a classificação de risco deve considerar tanto a capacidade de evasão quanto o comportamento concreto observado depois que o ambiente WSL é ativado.
- Windows 10 com WSL disponível, em especial ambientes que permitiam o recurso em conjunto com modo desenvolvedor.
- Endpoints nos quais produtos de segurança não monitoram processos Pico, binários ELF,
Bash.exe,LxRun.exee chamadas traduzidas porlxcore.sys. - Estáções em que contas locais ou processos maliciosos podem obter privilégios administrativos para habilitar recursos, alterar registro e iniciar o ambiente Linux.
- Sistemas com uso legítimo de WSL, onde a presença do subsistema pode mascarar atividade anômala se não houver linha de base comportamental.
A caça deve começar por eventos de habilitação do WSL e por mudanças transitórias de configuração. Como a técnica pode ativar e desativar chaves de modo desenvolvedor em sequência curta, o valor atual do registro não é suficiente. É necessário consultar auditoria de alteração de registro, trilhas de EDR, eventos de gerenciamento de recursos do Windows e linha do tempo de criação de processos. Mudanças em AllowAllTrustedApps e AllowDevelopmentWithoutDevLicense próximas à execução de LxRun.exe, Bash.exe ou carregamento de lxss.sys e lxcore.sys devem ser investigadas, principalmente quando o host não é classificado como estáção de desenvolvimento.
No endpoint, a defesa deve correlacionar criação de processos Windows com processos Pico e execução Linux. A ausência de estruturas típicas de processos NT não deve reduzir a severidade da investigação; ao contrário, processos Pico associados a atividade de arquivo, rede ou execução de binários inesperados precisam entrar na mesma cadeia temporal de detecção. A execução de Wine dentro do WSL é um sinal particularmente relevante quando aparece em hosts corporativos sem justificativa. O objetivo não é bloquear todo uso de WSL, mas identificar quando o subsistema está servindo como intermediário para cargas Windows ou Linux que não pertencem ao padrão operacional do usuário.
A telemetria de sistema de arquivos também é importante. Durante a instalação do ambiente, o arquivo lxss.tar.gz aparece em diretório oculto sob %APPDATA% antes da extração. Alterações nesse arquivo, troca de conteúdo entre download e extração, criação de estruturas Linux inesperadas e escrita em áreas do Windows a partir de caminhos montados em /mnt devem ser preservadas em logs e snapshots forenses. Em rede, a instalação do sistema Linux a partir de servidores Microsoft pode parecer legítima; por isso, o valor analítico está na sequência completa: ativação do recurso, preparação do ambiente, execução de binários e comportamento pós-execução.
- Alterações rápidas nas chaves
AllowAllTrustedAppseAllowDevelopmentWithoutDevLicense, especialmente seguidas de retorno ao valor anterior. - Carregamento ou ativação de
lxss.syselxcore.sysem hosts que não possuem WSL aprovado. - Execução de
Bash.exeouLxRun.exepor processo pai incomum, conta sem perfil de desenvolvimento ou sessão com privilégio administrativo inesperado. - Criação, modificação ou troca de
lxss.tar.gzem pasta oculta sob%APPDATA%durante a instalação do ambiente Linux. - Uso de Wine dentro do WSL para acionar binários EXE, principalmente quando combinado com acesso a diretórios Windows por
/mnt. - Escrita em diretórios sensíveis do Windows a partir do ambiente Linux, limitada pelas permissões do token que iniciou a sessão.
A resposta deve separar três frentes: governança do recurso, visibilidade técnica e contenção de comportamento malicioso. Primeiro, organizações precisam decidir onde o WSL é permitido. Em estáções sem necessidade de desenvolvimento, o recurso deve permanecer desabilitado e sua habilitação deve gerar alerta. Em máquinas de engenharia, a permissão deve vir acompanhada de linha de base: usuários autorizados, distribuições Linux esperadas, processos normais, padrões de acesso a /mnt e ferramentas legítimas instaladas. Sem essa linha de base, o WSL vira uma área cinzenta entre administração legítima e evasão.
Segundo, os controles de endpoint devem suportar processos Pico e integrar as APIs disponibilizadas para monitoramento desse tipo de execução. Produtos que observam apenas processos NT tradicionais, chamadas Win32 comuns ou executáveis PE podem perder parte da cadeia. O monitoramento precisa enxergar binários ELF, eventos de inicialização do WSL, tradução de chamadas, carregamento de drivers relacionados e relação entre processo pai Windows e execução dentro do ambiente Linux. Também é necessário registrar alterações de registro com precisão temporal suficiente para capturar mudanças breves.
Terceiro, em um host suspeito, a contenção deve preservar evidências antes de remover o ambiente. O time deve coletar linha do tempo de processos, eventos de registro, estado dos recursos Windows, presença de lxss.tar.gz, conteúdo do sistema de arquivos Linux quando aplicável, histórico de execução e evidências de acesso a NTFS por /mnt. A análise deve focar na carga acionada e não apenas no subsistema: Bashware descreve a rota de evasão, mas o dano final depende do binário executado. Depois da contenção, revise permissões administrativas locais, políticas de habilitação de recursos e cobertura de EDR para WSL.
A mitigação também exige validação prática. Não basta confirmar que um agente de segurança está instalado; é necessário testar se ele registra eventos do WSL, processos Pico, execução de ELF e uso de Wine. Ambientes que aceitam WSL devem ter alertas calibrados para mudanças de configuração, instalação não autorizada de distribuições, execução de ferramentas de compatibilidade e acesso incomum a caminhos montados. A correção mais robusta combina endurecimento do Windows, redução de privilégios locais, auditoria contínua e atualização dos produtos de segurança para tratar o WSL como parte real da superfície de execução do endpoint.
- Manter WSL desabilitado em estáções que não precisam do recurso e alertar qualquer habilitação não autorizada.
- Restringir privilégios administrativos locais, pois a técnica depende de permissões capazes de alterar configuração do sistema e preparar o ambiente.
- Auditar alterações em
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlockcom retenção suficiente para capturar mudanças transitórias. - Exigir que EDR, antivírus e ferramentas de inspeção monitorem processos Pico, execução ELF,
Bash.exe,LxRun.exe,lxss.syselxcore.sys. - Criar linha de base para hosts que usam WSL legitimamente, incluindo distribuições, usuários, processos, ferramentas e padrões de acesso a
/mnt. - Investigar uso de Wine dentro do WSL quando não houver justificativa operacional documentada.
- Preservar artefatos do sistema de arquivos Linux e linha do tempo de instalação antes de remover o recurso em resposta a incidente.
0 Comentários