XLoader esconde servidor de comando e controle entre domínios isca

Análise do sucessor do Formbook mostra que a comunicação com o C&C não depende de probabilidade baixa: o malware usa domínios falsos, respostas HTTP camufladas e lógica criptografada para ocultar o servidor real.

Componente	XLoader para Windows, sucessor do Formbook, com configuração contendo uma URI principal e 64 domínios.
Vetor	Após execução e injeção em explorer.exe, o malware seleciona domínios da configuração e substitui posições por domínios isca e pelo C&C real.
Impacto	A infraestrutura de comando e controle fica disfarçada entre domínios aparentemente legítimos, enquanto comandos são entregues quando o servidor responde com 200 OK e corpo criptografado.
Prioridade	Tratar tráfego HTTP com respostas 404 Not Found recorrentes como sinal insuficiente de benignidade e correlacionar amostras, domínios recorrentes, hospedagem e comportamento pós-injeção.
Artefatos	Listas de 64 domínios por amostra, URI principal, respostas HTTP geradas por script, caminhos de campanha e scripts PHP de painel.
Mitigação	Bloquear e investigar domínios recorrentes associados a amostras, revisar telemetria de processos injetados e isolar endpoints com comunicação compatível com o fluxo descrito.

Resumo técnico

XLoader é descrito como um sucessor do Formbook, uma família de malware voltada ao roubo de dados. A investigação técnica mostra que a proteção da infraestrutura de comando e controle não é apenas uma consequência de domínios isca, mas parte de um fluxo desenhado para confundir sandboxes, pesquisadores e análises baseadas somente em tráfego observado. A aparência inicial sugeria que o malware teria baixa chance de contatar seu servidor real, porque cada amostra carrega uma URI principal e uma lista de 64 domínios, muitos deles registrados por entidades diferentes, com aparência legítima ou simplesmente estacionados. Essa leitura, porém, não explicava a confiabilidade esperada de um malware vendido como serviço e usado para exfiltrar dados de sistemas infectados.

A característica central é que a lista de domínios não deve ser interpretada como um conjunto simples de destinos aleatórios. Em amostras coletadas em volume, alguns domínios voltaram a aparecer em diferentes configurações, e cada amostra analisada continha exatamente um domínio pertencente a esse conjunto recorrente. Esses domínios compartilhavam propriedades relevantes: haviam sido registrados havia menos de um ano, usavam o registrador Namecheap e estavam hospedados na própria Namecheap. A combinação entre recorrência, posicionamento único por amostra e semelhança de infraestrutura indicou que o servidor real de comando e controle estava escondido dentro da lista, e não necessariamente localizado na URI principal.

O comportamento de rede também foi construído para reduzir sinais óbvios. A resposta normal ao check-in do XLoader se parece com uma página HTTP comum de 404 Not Found, o que dificulta separar servidor malicioso de servidor legítimo quando a análise observa apenas código de status e conteúdo de erro. O servidor retorna 200 OK apenas quando está pronto para entregar comando ao bot, com o comando criptografado no corpo da resposta. Como servidores legítimos também podem responder 200 OK a uma requisição semelhante, o status HTTP isolado não é uma evidência conclusiva. A defesa precisa combinar endpoint, rede, amostra e contexto de infraestrutura.

Fluxo técnico

A configuração do XLoader segue a mesma ideia estrutural observada no Formbook: uma URI principal e uma lista de 64 domínios. No Formbook, a lógica seleciona 16 domínios da lista e substitui um deles pela URI principal, o que leva a uma leitura natural de que a URI principal seria sempre usada e que os demais domínios funcionariam como iscas ou ruído. Como a configuração do XLoader tem o mesmo formato, a interpretação inicial foi semelhante. A diferença decisiva aparece quando a execução é observada em profundidade, especialmente na parte do código que fica criptografada e só é descriptografada depois que o malware é injetado no processo explorer.exe.

A análise de caixa-preta em sandbox criou uma percepção enganosa. Em execuções observadas, o malware acessava 14 domínios da lista de iscas e um domínio derivado da URI principal, que também se comportava como isca. Esse padrão sugeria que a probabilidade de contato com o C&C real seria inferior a 22% e, em várias execuções, nenhuma comunicação direta com o servidor real aparecia. O código, no entanto, mostrou que essa conclusão era incompleta. Uma função criptografada escolhe 16 domínios da configuração, gera dois números aleatórios diferentes entre 0 e 15 e usa esses números como posições de substituição: uma posição recebe o domínio falso associado à URI principal e outra recebe o domínio real de comando e controle.

Antes de inserir o domínio real na lista final de alvos, o malware verifica se o índice do domínio real já está presente entre os domínios selecionados. Em seguida, armazena a posição do C&C real para uso posterior. Esse detalhe muda a interpretação do fluxo: a infraestrutura real não é abandonada em favor de discrição; ela é inserida de forma controlada em meio ao conjunto de destinos, enquanto a visibilidade externa continua parecendo compatível com uma seleção probabilística de domínios isca. A técnica protege a infraestrutura contra análises superficiais sem eliminar a capacidade de contato com o servidor necessário à operação.

A descoberta de painéis também reforça a natureza da infraestrutura. Como o XLoader é vendido por assinatura e não fornece o código-fonte do painel de C&C aos clientes, os operadores dependem de uma infraestrutura centralizada mantida pelos criadores. Painéis compatíveis com campanhas foram identificados por diferenças entre respostas de erro geradas por script e respostas de erro geradas diretamente pelo servidor HTTP. Quando uma campanha está ativa, uma resposta de erro pode ser produzida pelo script do painel; quando a pasta da campanha não existe, a resposta tende a vir do servidor. Esse comportamento permite distinguir, em análise defensiva, campanhas ativas de caminhos inativos sem depender de acesso ao conteúdo operacional.

Superfície afetada

A superfície afetada envolve endpoints Windows capazes de executar o XLoader, especialmente quando há sinais de injeção no explorer.exe e conexões HTTP para múltiplos domínios embutidos na configuração da amostra. O risco não se limita a um único domínio exposto em uma URI principal, porque o servidor real pode estar oculto entre 64 entradas que variam de uma amostra para outra. Muitas dessas entradas podem parecer legítimas, estacionadas ou não relacionadas, o que reduz a eficácia de bloqueios baseados apenas em reputação estática ou em uma leitura única da configuração.

O modelo de serviço também altera a superfície de investigação. Diferentemente do Formbook, cujo código-fonte de painel foi vazado, o XLoader centraliza o C&C e limita a capacidade dos clientes de criar servidores próprios. Isso significa que múltiplas campanhas podem estar apoiadas em infraestrutura controlada pelos criadores do malware, com caminhos independentes e painéis separados hospedados no mesmo servidor. Para equipes de segurança, a hipótese operacional deve considerar coexistência de campanhas e separação por caminhos, sem presumir que um único host representa uma única operação.

• Endpoints Windows com execução de XLoader e injeção observável em explorer.exe.
• Amostras contendo uma URI principal e lista de 64 domínios, com um domínio real misturado a iscas.
• Domínios recorrentes entre amostras diferentes, especialmente quando compartilham registrador, hospedagem e janela recente de registro.
• Painéis de campanha que podem responder com páginas de erro geradas por script, diferentes de erros HTTP produzidos pelo servidor.
• Infraestrutura centralizada associada ao modelo de assinatura do malware, com possibilidade de múltiplos painéis sob caminhos distintos.

Hunting e telemetria

A caça deve partir da premissa de que a ausência de um 200 OK com comando não elimina comprometimento. O padrão normal de check-in pode produzir respostas 404 Not Found aparentemente comuns, e o servidor real pode ser acessado em meio a múltiplos destinos que funcionam como ruído. Em proxy, EDR, NDR e DNS, o sinal mais útil é a combinação de processo, sequência de domínios, repetição de padrões e relação com amostras analisadas. Uma consulta isolada para um domínio estacionado ou uma página 404 não é suficiente; o valor está na correlação entre vários contatos feitos em curto intervalo por um endpoint suspeito.

No endpoint, a etapa crítica é observar o comportamento após a injeção no explorer.exe, porque a parte do código responsável pela escolha de domínios fica criptografada até esse ponto. Sandboxes que encerram a análise cedo, que não acompanham a injeção ou que analisam apenas os primeiros contatos de rede podem classificar equivocadamente os destinos como iscas sem identificar o C&C real. A telemetria deve capturar criação de processo, injeção, memória descriptografada quando disponível, conexões de saída associadas ao processo injetado e padrões HTTP com respostas de erro semelhantes, mas geradas por origens distintas.

Em inteligência de ameaças, a correlação entre amostras é essencial. Se listas de 64 domínios forem extraídas de múltiplas amostras, domínios que aparecem repetidamente em conjuntos diferentes merecem prioridade, principalmente quando cada amostra contém exatamente um representante do conjunto recorrente. Propriedades de infraestrutura, como registrador, provedor de hospedagem e idade do domínio, ajudam a separar ruído de candidatos a C&C. Essa técnica deve ser usada com cautela: o contexto sustenta a análise de recorrência e infraestrutura, mas não autoriza classificar qualquer domínio no mesmo provedor como malicioso.

• Sequências de conexões HTTP para múltiplos domínios embutidos em uma mesma amostra.
• Respostas 404 Not Found recorrentes associadas ao mesmo processo ou à mesma cadeia de execução.
• Eventos de injeção em explorer.exe antes da etapa de comunicação com domínios configurados.
• Domínios que se repetem em listas extraídas de amostras diferentes, com apenas um representante recorrente por amostra.
• Diferenças entre páginas de erro geradas por script e erros retornados diretamente pelo servidor HTTP.
• Respostas 200 OK acompanhadas de corpo criptografado em fluxos compatíveis com check-in de bot.

Mitigação

A resposta deve começar pelo isolamento de endpoints com execução confirmada ou suspeita de XLoader, seguido de coleta de memória, artefatos de processo e registros de rede. Como a lógica de seleção dos domínios é revelada apenas depois da injeção em explorer.exe, a coleta deve preservar evidências pós-execução e não depender somente da configuração extraída em repouso. A contenção de rede deve priorizar domínios confirmados por correlação entre amostras e telemetria interna, evitando bloqueios amplos baseados apenas em registrador ou provedor de hospedagem.

A análise de amostras deve extrair a URI principal, a lista de 64 domínios e os índices usados para substituição quando o código descriptografado estiver disponível. Esses dados devem alimentar listas internas de detecção e enriquecimento, mas não devem ser tratados como indicadores equivalentes. A URI principal pode funcionar como isca, a maioria dos domínios pode ser ruído, e o domínio real pode estar em posição aleatória dentro da lista final. A triagem defensiva precisa manter essa distinção para reduzir falsos positivos e evitar que a investigação se concentre apenas no destino mais evidente.

Após contenção, a equipe deve revisar credenciais, sessões e dados sensíveis acessíveis ao usuário comprometido, porque o XLoader pertence à categoria de ladrões de informações. O contexto técnico confirma foco em exfiltração de dados por malware, mas não fornece tipos específicos de dados coletados nesta campanha; portanto, a avaliação deve partir dos privilégios do usuário, aplicações utilizadas no host e registros locais disponíveis. A restauração do endpoint deve ser acompanhada de rotação de credenciais relevantes, validação de persistência e monitoramento de novas tentativas de comunicação com domínios da configuração.

• Isolar hosts com sinais de execução de XLoader ou comunicação compatível com listas de domínios da amostra.
• Coletar telemetria de processo, memória e rede após a injeção em explorer.exe.
• Extrair e comparar listas de 64 domínios de múltiplas amostras para identificar recorrência controlada.
• Diferenciar URI principal, domínios isca e candidatos a C&C real antes de criar bloqueios permanentes.
• Monitorar respostas HTTP 404 Not Found e 200 OK no contexto do processo emissor, não apenas pelo código de status.
• Rotacionar credenciais expostas ao endpoint comprometido e validar ausência de persistência antes de retorno à operação.