Microsoft desarticula serviço de assinatura de malware usado em ataques de ransomware

A operação atribuída ao Fox Tempest abusava do Artifact Signing para gerar certificados de 72 horas e entregar binários maliciosos assinados como software legítimo.

Componente	Serviço MSaaS operado pelo Fox Tempest, com abuso do Artifact Signing para assinatura fraudulenta de binários maliciosos.
Vetor	Clientes criminosos enviavam arquivos para assinatura por meio do portal signspace[.]cloud ou de máquinas virtuais pré-configuradas, recebendo executáveis assinados com certificados de curta duração.
Impacto	Binários de ransomware, stealers e outros malwares podiam aparentar origem legítima, reduzindo atrito de execução e dificultando controles baseados apenas em reputação ou assinatura digital.
Prioridade	Caçar binários recentemente assinados com certificados de curta validade, revisar execuções disfarçadas de ferramentas legítimas e bloquear indicadores ligados à infraestrutura do serviço.
Artefatos	signspace[.]cloud, máquinas virtuais hospedadas em infraestrutura de terceiros, certificados de assinatura válidos por 72 horas e binários mascarados como AnyDesk, Microsoft Teams, PuTTY e Cisco Webex.
Famílias associadas	A atividade viabilizou implantação de Rhysida por atores como Vanilla Tempest e distribuição de famílias como Oyster, Lumma Stealer e Vidar; também houve vínculos com afiliados de INC, Qilin, BlackByte e Akira.
Mitigação	Atualizar detecções, revogar confiança indevida em arquivos apenas por assinatura, correlacionar assinatura com origem, caminho, reputação, telemetria de execução e comportamento pós-instalação.

Resumo técnico

A Microsoft desarticulou uma operação de malware-signing-as-a-service atribuída ao ator financeiramente motivado Fox Tempest. O serviço abusava do Artifact Signing, solução gerenciada de assinatura de código anteriormente conhecida como Azure Trusted Signing, para gerar certificados fraudulentos de curta duração e assinar arquivos maliciosos entregues a outros grupos criminosos. A operação de interrupção recebeu o codinome OpFauxSign e envolveu a tomada do site signspace[.]cloud, a retirada de centenas de máquinas virtuais usadas na operação e o bloqueio de acesso a um ambiente que hospedava o código subjacente do serviço.

O risco técnico central não estava apenas na presença de malware assinado, mas no enfraquecimento de um mecanismo que muitos fluxos defensivos usam como sinal de confiança. Um binário assinado digitalmente tende a enfrentar menos atrito em controles de segurança, decisões de usuário, regras de allowlist e processos de análise automatizada. Ao transformar assinatura de código em serviço pago para criminosos, o Fox Tempest criou uma etapa de infraestrutura que podia ser reutilizada por operadores de ransomware, distribuidores de stealers e afiliados especializados em acesso inicial. A atividade é atribuída como ativa desde maio de 2025 e foi associada a comprometimentos de máquinas e redes em vários países.

Fluxo técnico

O fluxo operacional combinava identidade fraudulenta, contas de nuvem, certificados e uma interface de assinatura para clientes criminosos. Para obter certificados emitidos por um serviço legítimo, o solicitante precisava passar por validações de identidade compatíveis com credenciais verificáveis. Esse requisito indica uso provável de identidades roubadas nos Estados Unidos e no Canadá para aparentar uma entidade legítima e obter as credenciais necessárias à assinatura. Depois disso, o serviço SignSpace permitia que arquivos enviados por clientes fossem processados com certificados controlados pelo operador, criando executáveis que mantinham aparência de software confiável durante uma janela de validade de 72 horas.

O modelo evoluiu em fevereiro de 2026, quando o operador passou a oferecer máquinas virtuais pré-configuradas em infraestrutura da Cloudzy. Em vez de depender apenas de um portal de upload, clientes podiam acessar ambientes preparados pelo próprio operador, enviar artefatos maliciosos e receber binários assinados. Essa mudança reduzia a exposição operacional do Fox Tempest, concentrava a atividade em infraestrutura sob controle do serviço e simplificava o ciclo de entrega para compradores. Documentos judiciais indicam que o serviço foi comprado e testado entre fevereiro e março de 2026, o que permitiu validar a mecânica de assinatura, o modelo de acesso e o papel da infraestrutura na entrega de malware assinado.

A monetização seguia um padrão de serviço criminoso de alto valor: compradores pagavam entre US$ 5.000 e US$ 9.000 para assinar código. O resultado podia ser um ransomware, um stealer ou um loader com nome e aparência de aplicativo administrativo conhecido. O abuso incluía disfarces como AnyDesk, Microsoft Teams, PuTTY e Cisco Webex, nomes que podem circular em ambientes corporativos sem levantar suspeita imediata quando analisados apenas por aparência, metadados superficiais ou presença de assinatura. Esse detalhe é importante para defesa: assinatura válida não significa origem íntegra, cadeia de distribuição aprovada nem comportamento benigno.

Superfície afetada

A superfície exposta inclui estáções Windows, servidores, ambientes de acesso remoto, fluxos de instalação de ferramentas administrativas e pipelines defensivos que tratam assinatura digital como critério forte de confiança. Organizações que permitem execução com base em publisher, reputação genérica ou presença de certificado podem ter maior risco quando um binário malicioso é recém-assinado por uma cadeia considerada legítima. O problema também alcança equipes de desenvolvimento e nuvem, porque o abuso de serviços de assinatura depende de identidade, contas, assinaturas e perfis de certificado que podem ser criados ou manipulados fora dos controles internos da vítima final.

A atividade também afeta investigações de ransomware. A presença de arquivo assinado não deve encerrar a análise de procedência; ela precisa ser cruzada com origem de download, parent process, hora de assinatura, caminho no disco, primeira execução, conexões de rede e comportamento após a execução. Em campanhas associadas, foram observadas entregas de Rhysida, além de famílias como Oyster, Lumma Stealer e Vidar. Também há vínculos com afiliados ligados a INC, Qilin, BlackByte e Akira, o que mostra que a assinatura era uma capacidade transversal do ecossistema criminoso, não um detalhe restrito a uma única família de malware.

• Ambientes que aceitam binários assinados por regra ampla de allowlist sem exigir reputação, origem controlada ou hash aprovado.
• Estáções onde ferramentas como AnyDesk, Microsoft Teams, PuTTY e Cisco Webex são comuns e podem ser imitadas por nomes, ícones ou metadados.
• Controles de EDR, proxy, CASB e correlação de identidade que não relacionam assinatura digital com comportamento de processo, origem do arquivo e telemetria de rede.
• Ambientes de resposta a incidente que descartam rapidamente arquivos assinados durante coleta inicial ou varredura de persistência.

Hunting e telemetria

A caça deve começar por binários executados ou gravados recentemente que possuam assinatura válida, mas origem incompatível com o fluxo normal de distribuição. Procure arquivos baixados de diretórios temporários, compartilhamentos incomuns, perfis de usuário, pastas de ferramentas administrativas improvisadas e locais usados por scripts de implantação. A janela de validade de 72 horas dos certificados torna a linha do tempo essencial: hora de assinatura, primeira observação no ambiente, criação do arquivo e primeira execução devem ser comparadas. Um arquivo assinado minutos ou horas antes da execução, com baixa prevalência interna e sem origem de software management, merece análise manual.

Em rede, busque resoluções DNS, conexões HTTP ou tráfego de proxy envolvendo signspace[.]cloud, além de acessos remotos ou transferências de arquivo para máquinas virtuais externas não reconhecidas. A presença de Cloudzy em telemetria não prova comprometimento por si só, mas conexões para infraestrutura VPS desconhecida durante preparação de binários, transferência de executáveis ou execução de ferramentas administrativas devem entrar na investigação. Em endpoint, priorize eventos de execução de binários assinados que iniciam PowerShell, cmd, ferramentas de compressão, coleta de credenciais, enumeração de domínio, cópia lateral ou comunicação com destinos sem reputação consolidada.

• Execução de arquivos assinados recentemente, com certificado de curta validade, baixa prevalência e nome semelhante a ferramenta legítima.
• Criação de processos filhos incomuns a partir de binários que aparentam ser AnyDesk, Teams, PuTTY ou Webex.
• Downloads ou transferências de executáveis a partir de VPS, portais de upload, sessões RDP ou caminhos de usuário fora do catálogo interno de software.
• Registros de DNS, proxy e firewall contendo signspace[.]cloud ou domínios relacionados a infraestrutura de assinatura não autorizada.
• Alertas de stealer ou ransomware em máquinas onde o arquivo inicial foi considerado confiável apenas por assinatura digital.

Mitigação

A resposta deve tratar assinatura digital como um atributo de contexto, não como decisão definitiva de confiança. Controles de execução precisam combinar publisher, reputação, hash, caminho permitido, origem de distribuição, comportamento e prevalência no ambiente. Regras de allowlist que autorizam qualquer binário assinado por uma cadeia ampla devem ser revisadas, especialmente em estáções administrativas, servidores críticos e hosts usados por equipes de TI. Para arquivos suspeitos já executados, preserve amostras, metadados de assinatura, linha do tempo de criação e logs de rede antes de remover os artefatos, porque esses elementos ajudam a distinguir abuso de assinatura, acesso inicial e execução de payload posterior.

Organizações com uso legítimo de Artifact Signing ou fluxos equivalentes devem auditar contas, tenants, assinaturas, perfis de certificado, histórico de emissão e integrações de pipeline. A revisão precisa confirmar se não há identidades inesperadas, contas abandonadas, credenciais reutilizadas, service principals sem dono ou permissões excessivas capazes de solicitar assinatura fora do processo aprovado. Em paralelo, equipes de SOC devem atualizar regras para detectar binários assinados de baixa prevalência, reforçar correlação entre assinatura e comportamento e validar se produtos de EDR já incorporam indicadores e detecções relacionadas ao Fox Tempest.

• Bloquear e investigar qualquer resolução ou acesso histórico a signspace[.]cloud em DNS, proxy e firewall.
• Revisar allowlists que confiam em assinatura digital sem validar origem, hash, caminho, reputação e inventário aprovado.
• Criar hunting para binários assinados com validade curta, baixa prevalência e nomes de ferramentas administrativas conhecidas.
• Auditar contas de nuvem e fluxos de assinatura de código, removendo identidades sem dono, credenciais antigas e permissões excessivas.
• Para hosts com execução suspeita, coletar memória quando viável, preservar o binário assinado, revisar persistência, procurar stealer e validar movimentação lateral.
• Atualizar EDR, SIEM e controles de aplicação para correlacionar certificado, parent process, linha de comando, rede e comportamento pós-execução.