Operação contra empresas dos Estados Unidos inverte o fluxo de phishing, abusa de domínios confiáveis e executa um loader em PowerShell que instala persistência por TypeLib e carrega MixShell em memória.
| Componente | Campanha ZipLine, arquivos ZIP armados, atalhos .lnk, loader em PowerShell e implante MixShell em memória. |
| Vetor | O operador envia uma solicitação por formulário Contact Us; a própria organização alvo responde por e-mail e a conversa evolui até o envio de um ZIP hospedado em subdomínio de herokuapp.com. |
| Impacto | Execução de shellcode em memória, persistência por sequestro de TypeLib, comando e controle por consultas DNS TXT, fallback HTTP e possibilidade de operações de arquivo, shell reverso e proxy para movimentação interna. |
| Prioridade | Revisar respostas a formulários externos que evoluem para troca de arquivos, bloquear ou isolar ZIPs com .lnk, procurar alterações no CLSID {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B} e investigar DNS TXT anômalo. |
| Artefatos | Udate_Srv.sct, script:, cmd.exe /K, System.Reflection.Emit, GetProcAddress, VirtualAlloc, TypeLib, .lnk, .sct e consultas DNS TXT. |
| IoCs | Domínio tollcrm[.]com, endereço de servidor de nomes 172.210.58[.]69 e uso de subdomínios de herokuapp.com para entrega do arquivo ZIP. |
| Mitigação | Tratar links recebidos após contatos comerciais como entrada não confiável, aplicar análise detonada de anexos ZIP, auditar chaves COM/TypeLib de usuário, monitorar tráfego DNS TXT e remover persistência antes de rotacionar credenciais expostas no host. |
A campanha ZipLine combina engenharia social de baixa velocidade com execução técnica voltada a furtividade no Windows. O ponto central da operação é a inversão do fluxo tradicional de phishing: o atacante não inicia a conversa diretamente por e-mail com um anexo suspeito, mas envia uma mensagem por um formulário público de contato da empresa alvo. Quando a organização responde a essa solicitação, a primeira mensagem de e-mail parte do ambiente legítimo da vítima, o que reduz o atrito psicológico para o usuário e também pode contornar parte das regras de reputação que pesam mais fortemente mensagens recebidas sem relacionamento prévio. A conversa pode se prolongar por dias ou semanas, com pretextos comerciais como parceria, reunião, assinatura de NDA ou avaliação de impacto de IA, até o momento em que um arquivo ZIP é apresentado como documento necessário ao processo.
O pacote malicioso observado contém documentos isca em PDF e DOCX e um atalho .lnk responsável por iniciar a cadeia de execução. O ZIP também pode carregar um script em PowerShell embutido no próprio conteúdo binário, extraído e executado pelo fluxo iniciado pelo atalho. Após a execução inicial, o loader estabelece persistência por sequestro de TypeLib, cria um arquivo Udate_Srv.sct com scriptlet XML, usa o moniker script: para execução por COM e carrega shellcode em memória. O payload final é o MixShell, um implante customizado que resolve APIs do Windows dinamicamente, usa hashing ROR4 para evitar nomes de APIs em claro, mantém configuração logo após a região de código e prioriza comando e controle por consultas DNS TXT, com fallback para HTTP depois de falhas repetidas.
A etapa de acesso inicial depende de uma interação legítima criada pela própria vítima. O operador usa o formulário público de contato para se apresentar como possível parceiro ou solicitante de negócio. A equipe comercial ou administrativa responde, e a conversa passa a ocorrer em uma thread que, para ferramentas e usuários, aparenta continuidade normal de relacionamento. Esse detalhe é relevante para detecção porque controles baseados apenas em origem desconhecida, reputação de remetente ou anexo inesperado podem perder contexto: o arquivo chega após uma troca progressiva, com assunto comercial coerente e um link hospedado em infraestrutura legítima de plataforma como serviço. O uso de subdomínios de herokuapp.com acrescenta uma camada de confiança operacional, porque o domínio base é amplamente usado por aplicações benignas e pode não ser bloqueado em políticas corporativas amplas.
Quando o usuário abre o ZIP e aciona o .lnk, o atalho executa um comando que coordena a extração do script em PowerShell, substitui marcadores internos por caminhos reais do script e do atalho, e prepara a persistência. A técnica de TypeLib modifica a área de registro associada ao CLSID {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}, ligado a componentes Microsoft Web Browser. O novo apontamento leva ao arquivo local Udate_Srv.sct, que contém um scriptlet XML decodificado a partir de Base64. Como o mecanismo COM pode ser invocado por aplicações que incorporam componentes do Internet Explorer e por interações normais do explorer.exe, a execução pode ser reativada após reinicializações ou quando o objeto sequestrado é acessado, sem exigir nova ação explícita do usuário.
O scriptlet em JScript verifica se a cadeia principal já está em execução procurando um processo com cmd.exe e uma linha de comando que contenha o parâmetro /K. Quando não encontra esse padrão, ele cria um shell e executa cmd.exe /K set X=1&{cmd}, em que {cmd} representa o caminho do atalho malicioso. Esse desenho transforma o .lnk em mecanismo de reativação: se o payload for encerrado, a próxima chamada ao objeto COM hijacked pode executar novamente o atalho. Depois disso, o loader seleciona shellcode de 32 ou 64 bits conforme a arquitetura, decodifica um blob Base64 protegido por XOR com chave embutida e usa System.Reflection.Emit para construir delegates .NET em tempo de execução. Com esses delegates, resolve GetProcAddress, obtém ponteiros de função, chama VirtualAlloc, copia o shellcode para memória executável e o invoca sem gravar um binário adicional em disco.
A exposição principal está em organizações que permitem respostas humanas a contatos externos e que tratam conversas originadas por formulários públicos como interações comerciais confiáveis sem inspeção reforçada de anexos e links. Empresas de manufatura nos Estados Unidos aparecem como alvo no contexto observado, mas o padrão operacional não depende de um setor específico: qualquer organização com formulário público, fluxo de pré-vendas, compras, parcerias ou triagem de documentos pode reproduzir a condição necessária. O risco aumenta quando equipes administrativas têm permissão para baixar ZIPs da internet, abrir atalhos do Windows dentro de arquivos comprimidos ou executar conteúdo em estáções com controles fracos de script.
A campanha também explora reputação de infraestrutura. Domínios usados para contato foram selecionados para parecerem empresas legítimas, incluindo nomes compatíveis com LLCs registradas ou domínios antigos que podem ter histórico limpo. Alguns sites associados compartilham conteúdo, layout e fotografia, sugerindo uso de modelo reaproveitado para dar aparência corporativa. No estágio de entrega, nem todos os ZIPs observados continham payload ativo, o que indica possível seleção dinâmica por IP, agente de usuário ou outro indicador contextual. Esse comportamento dificulta a análise estática de uma URL isolada: uma equipe de segurança pode baixar um arquivo benigno enquanto o usuário alvo recebe uma versão armada do mesmo fluxo.
A superfície técnica no host Windows inclui interpretação de atalhos .lnk, execução de PowerShell, registro COM/TypeLib, criação de .sct, chamadas de APIs de alocação e execução em memória, além de tráfego DNS TXT de saída. Em rede, o C2 do MixShell usa consultas DNS para transmitir dados em partes menores, respeitando limite de 60 caracteres por subdomínio no desenho observado. Após seis falhas consecutivas em DNS, o implante pode alternar para HTTP preservando a lógica de criptografia e encapsulamento dos dados. A infraestrutura inclui tollcrm[.]com e o endereço 172.210.58[.]69 como servidor de nomes associado ao primeiro domínio C2 identificado.
- Estáções Windows de usuários que respondem a solicitações comerciais externas e abrem documentos recebidos após conversas por e-mail.
- Controles de e-mail que confiam em threads iniciadas pela organização ou em domínios de hospedagem amplamente usados.
- Ambientes que permitem execução de
.lnka partir de ZIP e não bloqueiamPowerShellinterativo ou carregamento refletivo em memória. - Resolvers DNS corporativos que não monitoram volume, entropia, comprimento e frequência de consultas TXT por host.
A investigação deve começar pelo relacionamento entre entrada no formulário, resposta corporativa e entrega posterior de arquivo. Logs de aplicação web ou CRM podem mostrar mensagens iniciais vindas de domínios recém-observados no ambiente, seguidas por threads de e-mail com pedido de reunião, NDA, avaliação de impacto de IA ou questionário operacional. No gateway de e-mail, a sequência relevante não é apenas o anexo final, mas a progressão temporal da conversa: um contato externo que recebe resposta da empresa e, dias depois, envia link para ZIP em herokuapp.com deve ser tratado como fluxo de risco, mesmo quando o domínio de hospedagem possui reputação geral aceitável.
No endpoint, a telemetria deve correlacionar abertura de ZIP, execução de .lnk, criação de processo cmd.exe com /K, invocação de PowerShell, uso de APIs .NET de emissão dinâmica e alterações de registro no CLSID {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}. A presença de Udate_Srv.sct é um artefato de alta relevância quando associada a moniker script: e modificação de TypeLib. Eventos de criação de processo podem revelar cadeia como Explorer ou ferramenta de compactação iniciando atalho, atalho chamando cmd.exe, e cmd.exe disparando PowerShell. Mesmo que o shellcode não deixe executável em disco, a preparação da persistência e o comportamento do loader oferecem sinais suficientes para detecção.
Na rede, consultas DNS TXT com subdomínios longos, fragmentados, repetitivos e associados a um identificador estável do host devem ser priorizadas. Como o MixShell usa um mutex que também funciona como identificador de C2, a máquina infectada tende a produzir padrões consistentes de comunicação. O limite de 60 caracteres por subdomínio e a marcação de fim de mensagem permitem hunting por sequências de TXT que parecem transmissão de dados, não simples resolução. A mudança para HTTP após seis falhas em DNS também deve ser buscada: um host que apresenta falhas repetidas de TXT para domínio suspeito e, logo depois, inicia tráfego HTTP para infraestrutura relacionada pode estar executando o fallback do implante.
- Eventos de e-mail ou CRM em que uma resposta interna a formulário público antecede link para ZIP hospedado em subdomínio de
herokuapp.com. - Execução de
.lnkdentro de diretórios temporários, área de downloads ou conteúdo extraído de ZIP recebido por e-mail. - Criação ou modificação de
Udate_Srv.scte alterações deTypeLibpara o CLSID{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}. - Processos
cmd.execom/Kdisparados por atalho, seguidos dePowerShelle chamadas relacionadas aSystem.Reflection.Emit. - Consultas
DNS TXTde alto volume, subdomínios próximos de 60 caracteres e fallback HTTP após falhas de resolução.
A resposta deve tratar a campanha como combinação de comprometimento de endpoint, abuso de confiança operacional e C2 furtivo por DNS. O primeiro passo é preservar evidências de e-mail, logs do formulário, URLs acessadas, ZIPs recebidos e telemetria do host antes de remover artefatos. Em hosts suspeitos, a contenção deve isolar a máquina da rede, bloquear resolução dos domínios associados, impedir tráfego DNS direto para fora do resolver corporativo e coletar registro, memória e histórico de criação de processos. A remoção somente do arquivo ZIP ou do atalho é insuficiente se a persistência por TypeLib já foi instalada; o CLSID afetado e o arquivo .sct precisam ser revisados e revertidos com validação posterior.
No controle preventivo, anexos ZIP provenientes de interações comerciais externas devem passar por detonação que preserve contexto de IP e agente de usuário, porque a campanha pode entregar conteúdo benigno em algumas condições e payload em outras. Políticas de endpoint devem bloquear execução de .lnk em arquivos comprimidos e restringir PowerShell para usuários que não precisam de automação administrativa. Regras de redução de superfície de ataque, controle de scripts, AppLocker ou WDAC ajudam a impedir que atalhos e scriptlets COM iniciem loaders. Para e-mail, a classificação deve considerar a cadeia completa: formulário externo, resposta interna, maturação da conversa e envio de link para plataforma legítima, em vez de depender apenas da reputação do domínio final.
Após a erradicação, equipes devem validar que não há consultas TXT residuais, que a chave COM não foi recriada e que não existem processos cmd.exe /K persistentes reativando a cadeia. Credenciais usadas no host devem ser avaliadas conforme exposição real: se houve sessão interativa, acesso a compartilhamentos, ferramentas internas ou tokens locais, a rotação deve ser priorizada. Como o implante oferece recursos de arquivo, shell reverso e proxy, a investigação precisa procurar movimentação lateral e acesso a recursos internos a partir do host inicial. A presença de componentes de backend com funções de execução de comandos, shell reverso e download por URL reforça que a operação deve ser tratada como intrusão com potencial de pós-exploração, não apenas como phishing bloqueado no usuário.
- Bloquear execução de
.lnka partir de ZIPs e aplicar detonação de anexos com variação de IP, agente de usuário e ambiente. - Auditar e restaurar entradas
TypeLibassociadas ao CLSID{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}quando houver alteração não autorizada. - Remover
Udate_Srv.sct, atalhos maliciosos e tarefas ou processos que relancemcmd.exe /Kapós coletar evidências. - Centralizar resolução DNS, alertar para TXT anômalo e bloquear comunicação com
tollcrm[.]come infraestrutura relacionada quando aplicável. - Treinar equipes que respondem formulários públicos para tratar pedidos de NDA, questionários e links de plataforma legítima como entradas externas que exigem validação técnica.
0 Comentários