📁 SCR, RMM e ClickOnce

Leitura de 4 min

Esta segunda apostila entra em dois casos que parecem diferentes na superfície, mas compartilham a mesma lógica: interação do usuário, software aparentemente legítimo e valor investigativo concentrado na cadeia de execução.

Ela continua a trilha iniciada em 📁 Fundamentos de Detection Engineering para Windows e mantém Detection.Wiki como referência-base.

Objetivo

Os dois estudos de caso desta etapa ensinam a reconhecer quando o atacante prefere abusar da normalidade em vez de depender de um artefato obviamente malicioso.

Casos abordados:

  1. Windows Screensaver Files and RMM Persistence
  2. ClickOnce Abuse

Parte I — .scr, execução e RMM

O que este caso ensina

O caso é didático porque mostra uma ideia simples e forte:

  • o arquivo parece inofensivo
  • o Windows aceita .scr como executável
  • o usuário executa
  • a cadeia termina instalando software remoto legítimo
  • a persistência e o acesso passam a se parecer com administração regular

O truque não está, necessariamente, em um exploit sofisticado. Muitas vezes está no abuso de confiança.

Conceitos centrais

.scr não é um formato inocente

No Windows, .scr é executável. Isso significa que:

  • pode parecer um arquivo visual ou banal
  • pode iniciar outros processos
  • pode ser executado manualmente pelo usuário
  • pode servir de gatilho de persistência por screen saver

RMM é faca de dois gumes

Ferramentas de Remote Monitoring and Management são legítimas e comuns em suporte e administração. Justamente por isso, também podem ser abusadas.

Exemplos conhecidos:

  • ScreenConnect
  • TeamViewer
  • AnyDesk
  • NinjaOne
  • Atera

O valor ofensivo vem do fato de que assinatura, produto conhecido e tráfego aparentemente normal reduzem suspeita inicial.

Cadeia típica do caso

  1. usuário baixa um .scr
  2. o .scr é executado em pasta do usuário
  3. ele dispara script ou intérprete auxiliar
  4. o fluxo chega a msiexec.exe
  5. um cliente remoto é instalado
  6. serviço, chave ou configuração é criada
  7. o host passa a aceitar acesso remoto persistente

O que procurar na investigação

Download

  • .scr vindo de navegador
  • pasta Downloads
  • FileOriginUrl
  • FileOriginReferrerUrl

Execução

  • .scr fora de C:\\Windows\\
  • pai explorer.exe
  • filhos como cmd.exe, wscript.exe e msiexec.exe

Instalação

  • MSI silencioso
  • criação de serviço
  • gravação em registro
  • escrita em Program Files ou ProgramData

Persistência e operação

  • serviço criado
  • artefatos de ScreenConnect ou ConnectWise
  • tráfego para relay ou domínio de RMM
  • alteração de configuração

Heurísticas úteis

  1. .scr fora de diretório padrão do Windows
  2. .scr gerando cmd.exe, wscript.exe ou msiexec.exe
  3. software RMM novo sem allowlist
  4. instalação silenciosa logo após arquivo vindo de navegador

Parte II — ClickOnce

O que é ClickOnce

ClickOnce é um mecanismo legítimo da Microsoft para implantação de aplicações .NET. Em ambiente corporativo, isso pode ser normal. O problema aparece quando esse mecanismo é usado como ponto de execução inicial ou proxy execution.

O binário-chave: dfsvc.exe

dfsvc.exe é o Deployment Service do ClickOnce. Quando um caso passa por abuso de ClickOnce, ele costuma ser pivô central da análise.

Perguntas úteis:

  • quem lançou dfsvc.exe?
  • houve relação com navegador?
  • apareceu rundll32.exe com dfshim.dll?
  • a origem foi URL externa?
  • houve escrita em AppData\\Local\\Apps\\2.0\\?

O diretório que importa

Um dos sinais mais úteis é:

%LOCALAPPDATA%\\Apps\\2.0\\

Se a investigação mostrar:

  • executável recém-implantado ali
  • DLL auxiliar ali
  • .exe.config ali
  • módulo não assinado carregado dali

então o caso merece triagem mais forte.

Cadeia típica

  1. usuário interage com link ou site
  2. ClickOnce é invocado
  3. dfsvc.exe faz a implantação
  4. arquivos vão para o cache do ClickOnce
  5. o app implantado executa
  6. módulos e configurações auxiliares são carregados
  7. pode surgir rede suspeita ou child process inesperado

Artefatos importantes

Processos

  • dfsvc.exe
  • app implantado
  • filhos inesperados do app

Arquivos

  • .application
  • .manifest
  • .deploy
  • .exe.config
  • DLLs no cache do ClickOnce

Rede

  • manifesto baixado
  • payloads .deploy
  • conexões externas posteriores
  • blob storage e domínios correlatos

Sinais fortes

  • dfsvc.exe vindo de navegador com URL externa
  • cache ClickOnce gerando .exe.config
  • módulo não assinado carregado por app em Apps\\2.0\\
  • app recém-implantado abrindo rede logo depois
  • child process improvável saindo do app ClickOnce

Comparando os dois casos

Aspecto.scr + RMMClickOnce
Vetor inicialexecutável disfarçadoapp ou manifesto aparentemente legítimo
Binário confiável abusadomsiexec.exe e RMMdfsvc.exe e ecossistema ClickOnce
Sinal forte.scr fora de C:\\Windows\\Apps\\2.0\\ + dfsvc.exe
Valor da detecçãocadeia de instalação remotacadeia de implantação e carga

Perguntas de estudo

  1. Por que dfsvc.exe não deve ser tratado automaticamente como malicioso?
  2. Por que a pasta Apps\\2.0\\ é tão útil?
  3. Qual a diferença entre “software legítimo” e “uso legítimo”?
  4. Por que allowlist de RMM costuma ser mais útil do que confiar só em antivírus?

Fechamento

Os dois casos reforçam a mesma lição: o ambiente costuma confiar mais no que já conhece. É exatamente aí que a detecção precisa ganhar contexto.

Continuidade

Passos adjacentes desta trilha:

Referências e apoio: