The SOC Files 5: Fantasma no pipeline ou uma violação fileless do SharePoint pelo Storm-2603

Sumário executivo

Em 2025, vários agentes de ameaça exploraram as vulnerabilidades CVE-2025-53770 e CVE-2025-53771 (vulnerabilidades do ToolShell) no Microsoft SharePoint local para obter execução remota de código por meio de solicitações HTTP especialmente criadas. Um deles implementou ransomware nos sistemas do alvo após explorar a vulnerabilidade com sucesso. A Microsoft atribui ao Storm-2603 essa atividade relacionada ao ToolShell e ao ransomware, distinguindo-a da atividade observada de outros agentes, que envolveu principalmente o roubo de credenciais, espionagem e exfiltração de dados.

Em dezembro, nossa análise retrospectiva identificou atividade que avaliamos ser consistente com as TTPs do Storm-2603. Nessa atividade, o invasor usou o processo do IIS como uma ponte em memória para a infraestrutura do cliente, mantendo a camada de acesso e controle inteiramente dentro do w3wp.exe, sem gravar nada no disco. Embora as atividades subsequentes de pós-exploração tenham gerado artefatos no disco, essa ponte usada para manter o acesso permaneceu residente na memória.

Vamos analisar esse ataque com mais detalhes.

Cronograma da intrusão: latência estratégica e exploração

A intrusão analisada neste relatório ocorreu em dois estágios, com uma lacuna temporal entre o acesso inicial e a atividade de exploração subsequente. A linha do tempo do ataque é a seguinte:

• 20 de dezembro – Fingerprinting da vulnerabilidade: uma única solicitação HTTP direcionada a um endpoint administrativo do SharePoint associado ao componente ToolPane para determinar se o host estava vulnerável ao CVE-2025-53770.
• 21 a 23 de dezembro – Latência tática: um período de três dias de silêncio seguiu a sondagem inicial, separando o fingerprinting da vulnerabilidade da atividade maliciosa subsequente e potencialmente reduzindo a probabilidade de detecção imediata.
• 24 de dezembro – Reengajamento de alta intensidade: na véspera de Natal, quando as equipes de segurança de muitas empresas estão com menos funcionários, toda a cadeia de execução remota de código (RCE) foi executada por meio do processo do IIS (w3wp.exe) no mesmo endpoint da sondagem inicial.
• 26 de dezembro – Descoberta de incidentes: o intervalo de três dias inicialmente impediu que a sondagem de 20 de dezembro fosse correlacionada com atividades maliciosas subsequentes, deixando o evento com baixa prioridade. A análise retrospectiva estabeleceu que a sondagem era a fase inicial da intrusão subsequente.

Fase de validação do acesso inicial

Fingerprinting da vulnerabilidade

Uma solicitação de fingerprinting de vulnerabilidade em 20 de dezembro marcou a primeira interação observada com o alvo. A solicitação teve origem em uma infraestrutura associada ao ONYPHE, uma plataforma de descoberta e gerenciamento da superfície de ataque abrangendo toda a Internet, usada para identificar ativos expostos, vulnerabilidades e ameaças cibernéticas. Embora ferramentas amplamente utilizadas, como Shodan e Censys, forneçam apenas uma lista de ativos expostos à Internet correlacionados com dados de código aberto sobre vulnerabilidades conhecidas, o ONYPHE verifica de fato se o sistema-alvo é realmente vulnerável.

As características da solicitação foram consistentes com as verificações de vulnerabilidades do mecanismo de busca ONYPHE, que usam sondagem ativas e não intrusivas para identificar sistemas expostos à Internet vulneráveis a CVEs específicos. Para o ToolShell, o ONYPHE adotou a abordagem desenvolvida por Niels Hofmans (hazcod). Ou seja, ele tenta injetar um marcador inofensivo no servidor-alvo para verificar se ele é vulnerável.

Essa fase funcionou como uma etapa de validação da superfície de execução do SharePoint exposta por HTTP:

• O alvo processou solicitações estruturadas por meio do pipeline do ASP.NET sem rejeitá-las
• O caminho da solicitação atingiu a lógica da aplicação capaz de manipular a entrada serializada
• Nenhum controle de defesa interrompeu ou alterou o fluxo de execução no limite da aplicação

Aproximadamente doze minutos depois, uma segunda conexão de entrada teve origem em uma infraestrutura associada à Pfcloud UG, um provedor que opera sob o modelo de hospedagem bulletproof (BPH). Considerando o momento e o histórico documentado do IP de atividades abusivas e de varredura, a conexão pode representar uma atividade subsequente de reconhecimento contra o alvo recém-identificado. Nenhuma tentativa de exploração foi realizada nessa etapa.
.

Exploração ativa: Papai Noel pegou seus dados e deixou um backdoor

A principal atividade maliciosa ocorreu em 24 de dezembro. O agente teve como alvo o mesmo host do SharePoint com uma solicitação especialmente criada, proveniente de 45.91.94.204 (45.91.92.0/22, ASN 63473, HostHatch, LLC). Isso resultou na execução de um web shell dentro do processo do IIS (w3wp.exe). O payload não foi gravado no disco; ele foi carregado diretamente no runtime do ASP.NET e utilizado durante o processamento das solicitações subsequentes. O implante permaneceu residente durante todo o tempo de vida do AppDomain afetado. Esse estado de runtime foi perdido quando o pool de aplicações foi reciclado ou quando o IIS foi reiniciado.

Ataque originado de um nó SPN

O endereço IP 45.91.94.204 é um nó da Safing Privacy Network (SPN). A SPN roteia cada conexão por um caminho de VPN multicamadas com vários nós de retransmissão, que podem ocultar o endereço IP de origem.

A SPN se apresenta como uma rede que oferece alto nível de proteção da privacidade do tráfego da Internet. Sua infraestrutura se assemelha em muitos aspectos à do Tor, mas apresenta algumas diferenças. Ela apresenta os seguintes recursos:

• Velocidade: desempenho próximo ao de uma VPN para transferência de dados em alta velocidade.
• Suporte à camada 3: oferece suporte a vários protocolos, como TCP, UDP e ICMP (ao contrário do Tor, que usa apenas TCP).
• Roteamento de aplicativos: tunelamento direto sem usar um navegador.
• Identidades múltiplas: uso simultâneo de nós de saída para contornar limites de taxa baseados em IP.
• Pacotes de tamanho fixo e padding que dificultam a análise do tráfego.

Ao mesmo tempo, a SPN é menos comum que o Tor e frequentemente consegue contornar listas de bloqueio padrão do Tor.

Arquitetura do web shell

O web shell que os invasores injetaram no runtime do w3wp.exe é um framework modular em memória, cuja execução é orquestrada pelo componente principal (G.cs) e estendida por várias unidades funcionais distribuídas entre diferentes namespaces.

A implementação segue uma estrutura de projeto modular em C#, onde cada funcionalidade é isolada em sua própria unidade de compilação e invocada dinamicamente no runtime.

Controle do pipeline e C2 do “G.cs”

Controle de pipeline

O principal componente do web shell é o G.cs. Ele orquestra o contexto de execução do implante, o ciclo de vida, o C2 e o gerenciamento de sessões.

Para garantir a persistência no runtime, o G.cs faz o seguinte:

• Registra um VirtualPathProvider personalizado usando o método não público RegisterVirtualPassProviderInternal da classe HostingEnvironment do ASP.NET, para que o ASP.NET o utilize no processamento de caminhos virtuais. O provedor é adicionado automaticamente à cadeia de provedores de caminhos virtuais registrados.
  
• Delega a política de tempo de vida do .NET Remoting do provedor ao provedor anterior na cadeia, preservando assim o comportamento existente de tempo de vida.
  

Além disso, para contornar as defesas e permitir que o VirtualPathProvider seja registrado mesmo que a aplicação em cujo AppDomain o web shell esteja sendo executado seja pré-compilada, o módulo implementa a técnica de subversão do controle de confiança (T1553):

• Usa reflexão para verificar se a aplicação foi pré-compilada.
• Extrai ponteiros para campos de estado internos da classe BuildManager, responsável por gerenciar a compilação da aplicação, e os modifica no runtime.
  
• Usa a reflexão mais uma vez para forçar a injeção no runtime.

O G.cs usa a função GetCacheKey() como o ponto de interceptação para o fluxo de processamento do caminho virtual. Ele processa as solicitações de entrada para o servidor do SharePoint e verifica seus cabeçalhos para filtrar as solicitações do invasor.

O User-Agent específico nos cabeçalhos da solicitação aciona a execução do web shell. Se a solicitação não corresponder a essa condição, o implante permanecerá inativo, dificultando o reconhecimento do tráfego.

Camada de comando e controle (transporte na memória)

O mesmo módulo principal (G.cs) implementa a camada de comunicação.

Em vez de depender de frameworks externos ou beacons padrão, usa um protocolo binário personalizado com ofuscação baseada em XOR para trocar dados com o C2. As comunicações se misturam ao tráfego normal da aplicação. Usando o hook GetCacheKey(), o módulo intercepta solicitações HTTP padrão. Quando um User-Agent específico é detectado nos cabeçalhos da solicitação, o módulo o analisa, extrai o payload e, se necessário, estabelece uma conexão TCP com um host-alvo dentro da rede do alvo.

Para oferecer suporte ao controle interativo, o G.cs estabelece um túnel proxy full-duplex, armazenando em memória os sockets ativos dos alvos para associar canais HTTP simultâneos de leitura e gravação.

Para pivoting e movimentação lateral, são permitidas conexões TCP do servidor de C2 a hosts arbitrários dentro da rede do alvo. O tráfego é encaminhado por proxy através do host do SharePoint.

Como pode ser visto nas capturas de tela, para implementar o proxy de tráfego, os invasores usaram a ferramenta suo5. Os autores a promovem como uma ferramenta estável de proxy de encaminhamento para cenários em que as conexões de saída com a Internet são proibidas.

Para aumentar seu desempenho, o G.cs manipula o ThreadPool, aumentando seus limites para operações simultâneas e o tempo limite máximo.

“Prog.cs”: entry point do executável e despachante de tarefas

O Prog.cs é o entry point que recebe os argumentos de linha de comando e os passa para o uk/London.cs. Este último atua como orquestrador, lidando com a análise dos comandos e com o escalonamento de privilégios (por meio de impersonation de pipes nomeados). Vamos analisá-lo com mais detalhes posteriormente. Quando o comando “suo5” é fornecido, o London.cs aciona o G.cs para se conectar ao runtime do ASP.NET como um shell em memória. Uma vez ativo, o G.cs processa o tráfego da Web recebido de forma independente, dentro da memória do servidor Web.

Módulos de interação do host

Os seguintes módulos fornecem recursos de interação direta com o sistema, cada um implementado como uma unidade separada. Esses módulos são acionados pelo London.cs quando recebe um comando correspondente do Prog.cs.

“FileDownloader.cs”

O módulo FileDownloader.cs baixa arquivos arbitrários de URLs externos fornecidos pelo C2. Ele armazena os arquivos baixados no diretório Program Data sem nenhuma interação do usuário.

“LoggedOnUsers.cs”

Este módulo enumera usuários conectados e identifica seus tipos de sessão (interativa, de serviço, remota). Os resultados são armazenados na memória. Os invasores podem recuperá-los usando os recursos de proxy e tunelamento fornecidos pelo G.cs.

“ProcessList.cs”

Este módulo lista os processos em execução com os caminhos completos dos executáveis correspondentes no disco. Os resultados são armazenados na memória. Os invasores podem recuperá-los via G.cs.

“NetworkInfo.cs”

O módulo extrai informações sobre conexões de rede existentes, incluindo os protocolos usados, IPs e portas locais e remotas e o estado da conexão. Ele também enumera interfaces de rede e cabeçalhos. Os resultados são armazenados na memória e podem ser recuperados pelos invasores via G.cs.

“MSI.cs”

Este módulo instala e executa silenciosamente pacotes MSI previamente baixados pelo FileDownloader.cs.

“User.cs”

Este módulo é responsável por criar contas administrativas usando o subsistema SAM RPC nativo (namespace SAMRPCNative) em vez das ferramentas de linha de comando padrão. Isso pode indicar uma tentativa de evitar a detecção e fornecer aos invasores um acesso furtivo e privilegiado aos sistemas alvo, que persiste depois que o web shell tiver concluído seu trabalho.

SAMRPCNative

O namespace SAMRPCNative implementa um wrapper C# de baixo nível via P/Invoke para a biblioteca nativa samlib.dll do Windows, composto por três tipos: SAMStructs.cs, SAMMethods.cs e SAMEnums.cs.

“SAMEnums.cs”

Implementa listas estruturadas de operações bit a bit e flags constantes que mapeiam códigos numéricos para seus significados de segurança relacionados no SAM e traduz códigos de retorno de status do sistema.

“SAMStructs.cs”

Define as estruturas de dados nativas necessárias para o alinhamento de memória do P/Invoke e para o marshalling. Formata e alinha as estruturas de dados com segurança.

“SAMMethods.cs”

Contém declarações de APIs externas (P/Invoke) importadas de samlib.dll para executar ações como conectar-se ao servidor SAM, criar usuários e abrir domínios.

Essa camada é fundamental para os invasores, pois permite as operações de contas.

Escalonamento de privilégios

O namespace uk contém recursos ofensivos para o escalonamento de privilégios. Para elevar os privilégios para SYSTEM, ele usa uma técnica de impersonation do token local por meio da interface do Encrypting File System Remote Protocol (EFSRPC), adotada da ferramenta EfsPotato.

Essa funcionalidade é implementada na classe uk/London. Ela cria um pipe nomeado malicioso, enquanto a classe EfsrTiny, uma versão reduzida da ferramenta EfsPotato, se conecta ao servidor RPC do LSASS.exe. Em seguida, a função London.RpcThread chama a função EfsRpcEncryptFileSrv de EfsrTiny com um caminho \\localhost especialmente criado. Isso engana o LSASS.exe para se conectar novamente ao pipe nomeado dos invasores. Por fim, a função London.Exp usa o ImpersonateNamedPipeClient para forçar a conexão e representar o token LSASS.exe e gerar um novo processo por meio de CreateProcessAsUser com privilégios de SYSTEM. Como o web shell reside no processo do IIS, ele tem o SeImpersonatePrivilege necessário para executar essa técnica.

O namespace uk também implementa uma camada mínima de cliente MSRPC, definindo estruturas como RPC_CLIENT_INTERFACE e MIDL_STUB_DESC explicitamente e, dessa forma, simulando um stub de interface. Isso permite a interação direta com o runtime de RPC do Windows (Rpcrt4.dll) sem depender de stubs gerados pelo MIDL ou de abstrações de RPC de nível mais alto, possibilitando o controle direto sobre o binding e o marshalling, sem as limitações das APIs de cliente padrão.

Atividade pós-exploração

Logo após a injeção do web shell, o processo do IIS (w3wp.exe) infectado iniciou o msiexec.exe para instalar um payload MSI remoto hospedado no armazenamento em nuvem Supabase. Esse payload MSI era o Velociraptor, uma ferramenta forense digital de código aberto e de resposta a incidentes (especificamente sua versão 0.73.4.0 vulnerável à CVE-2025-6264) que os invasores usaram de forma abusiva para executar comandos na rede-alvo.

Em outubro de 2025, a Cisco Talos informou que o Velociraptor estava sendo utilizado por agentes de ameaça como um framework de execução pós-comprometimento e atribuiu essa atividade ao Storm-2603. A ferramenta permite a execução arbitrária de comandos e pode ser usada para diversas finalidades. No nosso caso, ela foi utilizada para persistência, descoberta, coleta de dados e execução de payloads.

O agente de ameaça usou o Velociraptor para implementar vários mecanismos independentes de tunelamento, incluindo o Zoho Assist-Unattended Support para acesso remoto não autorizado, o tunelamento por meio da CLI do VS Code, o Cloudflare Tunnel e um utilitário leve de proxy reverso. Dessa forma, eles tentaram preservar o acesso mesmo que algumas de suas ferramentas fossem detectadas e removidas. Nessa etapa, eles também já não dependiam do ciclo de vida do processo do IIS e da vulnerabilidade do ToolShell.

Tentativas de desativação do EDR

Depois de obter acesso ao sistema-alvo, o agente de ameaça conseguiu carregar um driver vulnerável, que é usado ativamente por vários invasores para encerrar soluções de EDR. Conseguimos detectar o driver principal em C:\programdata\rsndispot.sys (054a32d6033b1744dca7f49b2e466ea2). Além disso, o invasor usou uma DLL maliciosa (2d9ebf9c042f596f435865b40edad928) como parte de um ataque de carregamento lateral. Essa DLL foi identificada como o software que desativa AV do ransomware Warlock. É possível que sua finalidade fosse encerrar soluções de segurança usando o driver vulnerável rsndispot.sys.

Tentativa de implementação de ransomware

Os invasores tentaram iniciar o ransomware no sistema comprometido. No entanto, o Módulo de defesa proativa no Kaspersky Endpoint Security bloqueou o processo de ransomware, impedindo efetivamente essa atividade. A DLL do malware que obtivemos foi identificada como Warlock ransomware.

O que os defensores devem realmente procurar

Desserialização do ToolPane e artefatos do CLR

Quando os invasores tentaram acessar o ToolPane, foi possível observar a presença tanto do assembly compilado dinamicamente App_Web_toolpane.aspx quanto do assembly auxiliar Microsoft.GeneratedCode no mesmo domínio de aplicação.

Ambos os assemblies são usados em cenários legítimos. Os assemblies App_Web_* são gerados durante a compilação normal de páginas ASP.NET, e o Microsoft.GeneratedCode é comumente produzido pelo XmlSerializer em fluxos de trabalho legítimos de serialização. No entanto, uma solicitação ao endpoint do ToolPane que resulta no carregamento imediato do Microsoft.GeneratedCode dentro da mesma janela de execução indica que o runtime está processando dados serializados fornecidos por meio da solicitação.

Detecção de exploração de desserialização

Em primeiro lugar, é altamente recomendável ler este artigo (em russo) sobre como as tentativas de exploit de desserialização no CLR devem ser detectadas, com exemplos de regras YARA e recomendações de monitoramento.

Abaixo, é fornecido um resumo da ideia principal da lógica de detecção.

As vulnerabilidades de desserialização devem ser tratadas como uma classe distinta de eventos de exploração. No CLR, a desserialização não é meramente a conversão de bytes em valores; é a reconstrução de um gráfico de objeto a partir do fluxo de entrada. A serialização e a desserialização são realizadas por formatadores, entre os quais um dos mais utilizados é o BinaryFormatter. O BinaryFormatter usa o formato NRBF, que define o fluxo como uma sequência de registros que descrevem classes, matrizes, primitivos e referências entre objetos. A forma do gráfico resultante é determinada pelos dados fornecidos ao desserializador. Operacionalmente, isso significa que o fluxo de entrada define não apenas valores, mas também os tipos específicos, relacionamentos e pontos do ciclo de vida que o runtime deve materializar.

A Microsoft declara explicitamente que o BinaryFormatter não é seguro e não pode ser tornado seguro; começando com o .NET 9, a implementação integrada ao .NET foi efetivamente removida do uso comum. Ainda assim, a própria Microsoft continua a usá-lo em seus produtos, incluindo o SharePoint, pois é robusto e fácil de usar. Para corrigir problemas relacionados ao BinaryFormatter, são necessárias alterações de arquitetura. Avisos comparáveis também se aplicam a mecanismos não seguros relacionados, incluindo LosFormatter (o mecanismo usado na página vulnerável).

O risco central da desserialização insegura é que o CLR pode resolver tipos inesperados, instanciar objetos fora das invariantes normais dos construtores e executar mecanismos de ciclo de vida especiais, como ISerializable, IObjectReference, IDeserializationCallback e métodos marcados com [OnDeserialized]. Em outras palavras, os dados controlados pelos invasores forçam o runtime a construir um gráfico contendo tipos com efeitos colaterais executáveis.

Uma estratégia de detecção prática deve, portanto, se concentrar em artefatos de construção de gráficos. Os eventos do loader CLR identificam os assemblies relevantes e os domínios de aplicação. A inspeção da memória e dos metadados revela então os nomes dos tipos e as estruturas de serializadores geradas associadas à cadeia de gadgets suspeita. Em cenários semelhantes ao ToolShell, a desserialização insegura geralmente produz assemblies auxiliares (evidenciados por eventos do loader) que contêm metadados com nomes de tipos totalmente qualificados, nomes de classes de gadgets e representações em forma de string dos tipos genéricos construídos (basta procurar por eles usando YARA). No nosso caso, procure artefatos como Microsoft.GeneratedCode, App_Web_toolpane.aspx* (evidência de desserialização nos eventos do loader) e strings que identifiquem ObjectDataProvider, ExpandedWrapper e LosFormatter (evidência de que o fluxo de entrada foi desserializado em objetos perigosos dentro desses assemblies). Observe que esses indícios não são significativos isoladamente; seu valor reside no fato de que eles mostram que o runtime já recebeu dados que requerem a geração de código auxiliar para a reconstrução de um gráfico de objeto perigoso.

Os objetos de gadget usados para explorar vulnerabilidades como o ToolShell são convenientemente representados em ferramentas de estilo corpus, como ysoserial.net/YSoNet, que agregam cadeias de gadgets conhecidas para desserialização insegura do .NET. Para fins defensivos, o valor desses projetos não reside na capacidade ofensiva, mas no catálogo de tipos e estruturas que podem ser pesquisados em fluxos, memória e assemblies auxiliares. A presença de qualquer um deles na memória ou em um assembly auxiliar deve ser tratada como um forte indício de exploração.

Para simplificar a detecção de exploits de desserialização, criamos uma ferramenta denominada CLRDeserializationExploitFinder. Ela fornece recursos para detectar tentativas de exploração do ToolShell, bem como outra cadeia de gadgets coberta pelo ysoserial.net.

Detectar um implante de web shell/runtime baseado em VPP

Um mecanismo baseado em VirtualPathProvider deve ser tratado como uma classe separada de implante no runtime (fileless envolvidos). No ASP.NET, o HostingEnvironment.RegisterVirtualPathProvider registra um novo provedor de caminho virtual (VPP) no sistema de compilação da aplicação. Uma vez registrada, a aplicação pode fornecer caminhos virtuais durante a compilação dinâmica, como se fossem páginas comuns armazenadas no disco. A compilação dinâmica não exige que o payload exista como um arquivo no sistema de arquivos. Ela opera inteiramente dentro do limite de confiança da própria aplicação. Durante o processo de compilação, arquivos temporários podem ser gerados, mas eles não podem ser tratados como artefatos forenses confiáveis. Como os VPPs também podem ser usados para fins legítimos, o modelo defensivo deve começar com um inventário das implementações legítimas do VirtualPathProvider. Em todos os outros casos, o registro ou uso de um novo VPP deve ser tratado como anômalo.

Para ver como a geração dinâmica de páginas virtuais usando ASP.NET, IIS e o CLR funciona, e como detectar tal atividade, você pode usar nosso projeto chamado VirtualPathProvider Lab.

A fonte de telemetria mais útil para essa técnica é o provedor ETW Microsoft-Windows-IIS-Configuration. Para detectar caminhos virtuais, os eventos 25 e 47 são de grande importância. O evento 25 registra o mapeamento de ConfigPath para PhysicalPath; o evento 47 registra o mapeamento do caminho de configuração para um diretório. No caso de um caminho com suporte de VPP, esses eventos criam uma inconsistência: o IIS e o ASP.NET se comportam como se o caminho tivesse uma representação física, enquanto o arquivo correspondente não existe no disco. No exemplo fornecido pelo VirtualPathProvider Lab, isso aparece como um mapeamento do recurso virtual googlecheck.aspx para um caminho físico onde nenhum arquivo real está presente. Essa discrepância entre a resolução da configuração e a realidade do sistema de arquivos constitui o principal indício do conteúdo virtual.

O segundo indício é mais negativo do que positivo. Para arquivos com suporte de disco, o IIS normalmente cria uma cadeia FileChangeNotificationMonitor, refletida nos eventos 17, 18, 19 e 21. No caso de caminhos virtuais fornecidos por um VirtualPathProvider personalizado, essa cadeia está ausente ou não corresponde ao perfil normal de um arquivo comum, pois não existe um objeto físico nem um ciclo de vida de alterações correspondente no disco. Assim, a combinação dos eventos positivos 25 e 47 com a ausência simultânea dos eventos 17/18/19/21 esperados para o mesmo caminho forma um padrão de detecção confiável: o caminho existe para o IIS como um recurso resolvido pela configuração, mas não está associado a um objeto no sistema de arquivos nem é acompanhado pelo monitoramento normal de alterações de arquivos.

Em resumo, o objetivo da busca é identificar a discrepância entre a forma como o IIS/ASP.NET resolve um recurso e o que está efetivamente presente no disco e na cadeia de monitoramento de alterações. Para aplicações conhecidas, esses casos podem ser filtrados por meio de uma lista de permissões com implementações legítimas de VirtualPathProvider. Todo o restante deve ser tratado como um possível implante no runtime e analisado por meio de ETW, verificação do sistema de arquivos e inspeção da memória do processo w3wp.exe.

Atribuição

A Microsoft rastreia o Storm-2603 como um agente de ameaça independente sem links identificados para outros grupos conhecidos. A Microsoft é cautelosa ao avaliar as motivações do agente, mas menciona que ele já implantou os ransomwares Warlock e LockBit após explorar ativamente vulnerabilidades do SharePoint local. No incidente analisado, observamos atividades semelhantes de exploração do SharePoint, bem como um componente de desativação do EDR associado ao ransomware Warlock e tentativas malsucedidas de executar o Warlock.

Outras intrusões documentadas identificam o Storm-2603 explorando vulnerabilidades públicas em gateways de e-mail de perímetro para obter acesso inicial, preparando posteriormente o framework Velociraptor com privilégios elevados e estabelecendo túneis persistentes e criptografados por meio de software comercial de gerenciamento remoto para coordenar movimentos laterais secundários. Isso está de acordo com o comportamento pós-exploração que observamos em nosso caso. Juntamente com o cenário de exploração do ToolShell, isso nos permite atribuir este caso ao Storm-2603 com confiança moderada.

Conclusão

A principal lição defensiva do incidente analisado neste artigo é que a exploração de um servidor do SharePoint voltado para a Internet pode permitir a execução de código totalmente fileless diretamente dentro do limite de confiança da aplicação. O Storm-2603 não precisou de um dropper convencional, de um serviço persistente nem de um endpoint de C2 exposto: implantou um web shell dentro do w3wp.exe, a partir do qual foi possível orquestrar o tunelamento, escalonamento de privilégios, acesso a credenciais e movimentação lateral. Portanto, a detecção precisa ir além da busca por web shells baseados em arquivos e se concentrar no comportamento do runtime: atividade anômala do w3wp.exe, conexões de saída inesperadas, coerção via RPC, impersonation de tokens e introdução de ferramentas de gerenciamento remoto ou de DFIR após o comprometimento da aplicação.

Para atribuir corretamente a atividade maliciosa e desenvolver medidas de resposta adequadas, as equipes de defesa devem reconstruir as cadeias de execução e as relações temporais entre as camadas da aplicação, do host e da identidade, preservar os dados de telemetria da memória e do IIS e correlacionar atividades de reconhecimento de baixa intensidade com as atividades privilegiadas subsequentes, em vez de avaliar os eventos isoladamente. Uma exploração confirmada do SharePoint com execução de código deve acionar a contenção no nível do host, a busca por mecanismos de persistência, a rotação de credenciais e das MachineKeys expostas e uma investigação orientada por TTPs, em vez de limitar a remediação à exploração inicial ou aos IoCs conhecidos.
Os produtos da Kaspersky são capazes de detectar as ameaças mencionadas neste artigo como:

• Trojan.MSIL.Agent.gen
• Trojan.Win64.DLLhijack.cdp

Indicador de comprometimento

Indicador de comprometimento	Descrição
45.91.94[.]204	Nó SPN
0xFD91321BF7FF7245DDA9B7B5D791ACE8	vskp2 – implante de web shell
hxxps://vdfccjpnedujhrzscjtq[.]supabase[.]co/storage/v1/object/public/image/v4[.]msi	Pacote Velociraptor vulnerável
0x3A55D8F8F29716C694671834D8C6CB29	C:\ProgramFiles\Velociraptor\Velociraptor.exe
hxxps://auth[.]qgtxtebl[.]workers[.]dev/	URL do servidor Velociraptor
199.232.210[.]172	Retransmissão de tráfego C2
0x991EC6E04413F2D4D29341C17A8A54D5	VS Code legítimo sendo usado de forma abusiva
0x3D553B9061C03F891CE97D7D2E64DDEE	VS Code Insiders para tunelamento
91.224.92[.]121	Servidor de C2 hospedado por um provedor de hospedagem bulletproof
49.51.132[.]100	Nó SPN
hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64[.]msi	Ferramenta legítima de tunelamento usada de forma abusiva
0x2C32E44A013CBFC5A323EFB7694701D2	Executável da ferramenta de tunelamento utilizada de forma abusiva
hxxps://files[.]catbox[.]moe/8f7vex[.]msi	URL de download do Zoho Assist Unattended Agent usada de forma abusiva
0x112A86ECA3CB5A0B5E20AB744CC5AF93	7z.exe renomeado para carregamento lateral
0xA930F81E3FB0A226EC5904D9043A17B8	C:\ProgramFiles(x86)\ZohoMeeting\UnAttended\ZohoMeeting.7z
204.76.203[.]219	Servidor de C2 hospedado por um provedor de hospedagem bulletproof
0x054a32d6033b1744dca7f49b2e466ea2	Driver vulnerável