Esta terceira apostila entra em casos mais traiçoeiros: técnicas menos óbvias, mais distribuídas em vários eventos e dependentes de boa correlação entre processo, arquivo, driver, image load e contexto do host.
Ela fecha a primeira trilha de Oficinas, partindo do que foi consolidado em 📁 SCR, RMM e ClickOnce e mantendo Detection.Wiki como apoio público principal.
Objetivo
Os casos desta etapa têm uma característica em comum: todos parecem mais confusos do que realmente são. Quando quebrados em blocos, revelam um padrão claro de abuso de confiança, persistência e evasão.
Casos abordados:
Python Persistence via .pth FilesBYOVD and KslD.sysDLL Sideloading with the Windows Bluetooth File Transfer WizardClickFix, Electron Script-jacking, and Mandatory User Profiles
Parte I — Persistência com .pth
O que é um .pth
No ecossistema Python, arquivos .pth influenciam caminhos e comportamento de inicialização. Em contexto defensivo, isso importa porque um .pth malicioso pode fazer código rodar quando o interpretador inicia.
É traiçoeiro porque:
- parece arquivo banal do ambiente Python
- vive em diretórios legítimos
- pode ser acionado por uso normal do interpretador
- em máquina de desenvolvedor, passa facilmente despercebido
O que procurar
Arquivo
.pthcriado ou alterado- pastas
site-packagesoudist-packages
Processo
python.exepythonw.exepip- terminal do usuário
Contexto
- host de desenvolvimento ou não
- instalação recente de pacote
- relação com
setuptools - mudança seguida de execução do Python
Lição real
Nem toda fonte de telemetria registra tudo do mesmo jeito. Em casos assim, Sysmon frequentemente complementa o que EDR filtra, resume ou simplesmente não expõe.
Parte II — BYOVD e KslD.sys
O que é BYOVD
Bring Your Own Vulnerable Driver é o uso de driver legítimo, assinado, mas vulnerável, para ganhar vantagem de execução, memória ou evasão.
Não se trata de “exploit tradicional” em um app. Trata-se de abuso de confiança no kernel.
Por que isso assusta
Quando o atacante ganha vantagem nesse nível, ele pode:
- burlar controles
- acessar memória sensível
- reduzir visibilidade defensiva
- chegar mais perto de credenciais
O que estudar nesse tipo de caso
Driver load
- nome do driver
- caminho
- hash
- momento de carregamento
Processo associado
- quem disparou
- se houve privilégio elevado
- que ferramenta, script ou contexto estava envolvido
Objetivo defensivo
- credential dumping
- evasão
- acesso privilegiado a memória
Ideias defensivas
- inventariar drivers presentes
- bloquear hashes ou famílias conhecidas
- monitorar
DriverLoad - correlacionar driver raro com processo suspeito
Parte III — DLL Sideloading com fsquirt.exe
O que é sideloading
DLL sideloading acontece quando um executável legítimo carrega um módulo malicioso colocado em local que ele consulta.
O valor ofensivo disso é óbvio:
- o processo parece confiável
- o nome do binário parece normal
- parte da defesa olha mais para “quem executou” do que para “o que foi carregado”
Por que fsquirt.exe importa
O assistente de transferência Bluetooth do Windows é interessante como estudo porque obriga o analista a olhar:
- image load
- staging em disco
- módulo fora do diretório esperado
Sinais fortes
bthprops.cplfora deSystem32,SysWOW64ouWinSxS- criação de
.cplem pasta do usuário fsquirt.exeassociado ao carregamento disso
A fórmula defensiva aqui é clara:
binário legítimo + módulo com nome esperado + local ilegítimo = pivô forte de investigação
Parte IV — ClickFix, Electron e NTUSER.MAN
O que torna esse caso complicado
Esta cadeia mistura várias camadas:
- engenharia social e ClickFix
- PowerShell escondido
- download e staging
- extração com LOLBin
- adulteração de app Electron
- mudanças defensivas locais
- persistência com hive de perfil mandatório
Não é um caso caótico. É um caso em etapas.
Dividindo a cadeia em blocos
- execução inicial
- staging
- modificação local
- defesa evasiva
- relaunch do app
- persistência
Quando a leitura segue esses blocos, o caso deixa de parecer “muito grande” e vira uma cadeia observável.
Por que Electron é alvo útil
Apps Electron costumam:
- existir em ambiente de usuário
- usar JS e recursos fáceis de adulterar
- residir em locais graváveis
- ser visualmente confiáveis para a vítima
O foco defensivo deve ir para:
resources\\app\\main.jspackage.jsonrenderer.js- módulos
.node - relançamento do app logo após alteração
O valor de NTUSER.MAN
NTUSER.MAN é associado a perfis mandatórios. Em contexto ofensivo, pode virar um artefato de persistência muito útil para hunting.
O raciocínio mais importante é direto:
a criação de NTUSER.MAN em endpoint comum já é, por si só, um grande sinal.
Sinais fortes deste caso
Processo
cmd.exe→powershell.exe- parâmetros ocultos ou encodados
tar.exetaskkill.exe- relançamento do app adulterado
Arquivo
- mudanças em
resources\\app\\ .nodemain.jsrenderer.jspackage.json- criação de
NTUSER.MAN
Registro e defesa
- exclusões no Defender
- Run keys ou outras persistências correlatas
Rede
- blob storage
- DNS correlato
- conexão externa logo após a modificação
Comparando os quatro casos
| Caso | Tipo principal | Sinal mais útil | Telemetria crítica |
|---|---|---|---|
.pth | persistência em ecossistema Python | .pth em site-packages | file events + process context |
| BYOVD | abuso de driver vulnerável | DriverLoad raro + hash | driver load + process context |
fsquirt sideload | hijack de carga de módulo | .cpl fora do caminho padrão | file events + image load |
| ClickFix/Electron | cadeia multiestágio | resources\\app adulterado + NTUSER.MAN | process + file + registry + network |
Checklist de estudo
Para .pth
- entender inicialização do Python
- procurar criação ou modificação de
.pth - correlacionar com execução posterior
Para BYOVD
- entender
DriverLoad - rastrear hash
- correlacionar com processo elevado
Para sideloading
- estudar o que o binário legítimo carrega
- monitorar módulos fora de caminho padrão
Para Electron e ClickFix
- mapear processo inicial
- detectar PowerShell escondido
- detectar mudança em
resources\\app - detectar alteração defensiva suspeita
- detectar
NTUSER.MAN
Fechamento
Esta etapa mostra, com mais força, que o defensor precisa dominar contexto, não só IOC. Os nomes mudam; os pivôs de investigação continuam sendo processo, arquivo, carregamento, persistência e rede.
Continuidade
Trilha relacionada:
Referências e apoio: