Written with AI assistance from the source video. The video is the authority.
6:21Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
Depois de saber de um incidente de segurança, você não tem tempo para ficar pesquisando no Google tarde da noite. Em maio de 2026, uma extensão maliciosa do Visual Studio Code foi distribuída, comprometendo as máquinas de desenvolvedores e vazando cerca de 3.800 repositórios de código-fonte corporativos. Nessa situação, apagar códigos cegamente ou formatar o notebook fará com que você perca todas as evidências forenses e impeça a descoberta da causa. Vamos verificar se houve invasão inspecionando diretamente os logs de execução do gerenciador de pacotes, os carimbos de data/hora (timestamps) de CLI globais e os privilégios dos processos em execução.
O gerenciador de pacotes grava registros de transações no diretório de cache do sistema durante o processo de instalação. O npm joga logs de depuração na pasta _logs dentro do caminho npm config get cache, enquanto o pnpm armazena artefatos em pnpm store path. Como pacotes maliciosos extraem variáveis de ambiente ou credenciais através de scripts executados no momento da instalação, você precisa começar verificando o histórico de execução do ciclo de vida.
O comando a seguir busca nos logs dos últimos 14 dias para identificar a adição de pacotes não autorizados ou a execução de scripts externos. Abra o terminal e execute os seguintes comandos exatamente como estão:
`bash
NPM_CACHE_DIR=$(npm config get cache)
find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
`
Verifique na tela de resultados se ganchos (hooks) preinstall ou postinstall que você não pretendia foram executados. Isso leva apenas 3 minutos. Se não houver registros de comunicação com URLs externas suspeitas, você pode respirar aliviado por enquanto em relação ao medo de contaminação direta em nível de pacote.
Atacantes inserem binários maliciosos em ferramentas CLI globais ou no cache do npx para persistirem dentro do laptop. Liste os pacotes instalados globalmente e compare as datas de criação e modificação dos arquivos na pasta de binários com os logs do sistema para verificar a integridade.
`bash
npm list -g --depth=0 --json
ls -lact $(npm config get prefix)/bin/
`
Se o momento da modificação coincidir com um fuso horário incomum, extraia e compare os valores de hash com o comando abaixo:
`bash
shasum -a 256 $(npm config get prefix)/bin/
`
Os scripts de instalação de pacotes são executados com as permissões da conta do desenvolvedor. Você deve encerrar processos daemon que estejam rodando em segundo plano:
`bash
ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep
lsof -i -P -n | grep -E "node|npm|pnpm"
`
Se um processo suspeito estiver se comunicando com um servidor C2 externo, encerre-o imediatamente:
`bash
kill -9 [PID]
npm config set ignore-scripts true
`
Um padrão comum em ataques à cadeia de suprimentos é mexer nos arquivos de configuração para sequestrar o registro. Atacantes inserem endereços de servidores mirror maliciosos no arquivo .npmrc do projeto ou nas configurações globais. Como eles alteram o caminho da URL de download dentro do arquivo de lock (lockfile) para fazer você baixar tarballs maliciosos durante a instalação real, você precisa examinar todas as configurações.
O procedimento para verificar se há substituições não autorizadas inseridas nas configurações locais e globais é o seguinte. Primeiro, extraia a lista de vinculações de configuração:
`bash
npm config list
pnpm config list
`
Em seguida, verifique se o escopo do registro privado da empresa está configurado corretamente:
`bash
npm config get @company:registry
`
Pesquise também diretamente para verificar se endereços de mirror externos estão hardcoded nos arquivos de configuração do diretório home do usuário e da raiz do projeto:
`bash
grep -Rn "registry" ~/.npmrc ./.npmrc
`
Ao seguir estas três etapas, você pode determinar em 5 minutos se um endereço de mirror estranho foi registrado.
Como os arquivos package-lock.json e pnpm-lock.yaml registram as URLs de origem para o download de dependências, você deve filtrar possíveis contaminações usando expressões regulares:
`bash
grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Se você usa o pnpm, digite o seguinte comando:
`bash
grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Se um arquivo de lock contaminado aparecer, você deve apagá-lo completamente e recriá-lo:
`bash
rm -rf node_modules package-lock.json pnpm-lock.yaml
npm cache clean --force
pnpm store prune
npm config set registry https://registry.npmjs.org/
npm ci --ignore-scripts
`
Ignorando a execução de scripts de ciclo de vida e reconstruindo a árvore de dependências em um estado imutável, você pode garantir um ambiente em seu estado original.
Binários maliciosos em ambientes Linux e Mac roubam o armazenamento de senhas do navegador e raspam chaves de API de IA, chaves de acesso da AWS (AWS Access Keys) e chaves SSH embutidas em variáveis de ambiente. Você deve verificar imediatamente no ambiente de terminal se suas credenciais foram expostas.
`bash
ls -la ~/.ssh/
env | grep -E 'TOKEN|KEY|SECRET|AUTH|AWS|GITHUB|OPENAI|ANTHROPIC'
grep -E '(ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}|bearer)' ~/.zsh_history ~/.bash_history
`
Se chaves expostas em texto plano forem encontradas, revogue-as imediatamente sem hesitar. Verifique também o escopo do token logado via GitHub CLI:
`bash
gh auth status
`
Exclua imediatamente tokens Clássicos (Classic Tokens) que concedem acesso a todos os repositórios. Ao recriar um PAT (Personal Access Token), especifique apenas repositórios específicos e limite o escopo de permissões apenas ao necessário para leitura.
Para isolar o localhost e os processos de desenvolvimento, você deve usar a estrutura DevContainer. Crie o arquivo .devcontainer/devcontainer.json na raiz do projeto e configure a imagem da seguinte forma:
`json
{
"image": "mcr.microsoft.com/devcontainers/javascript-node:22",
"postCreateCommand": "npm ci --ignore-scripts"
}
`
Ao iniciar o contêiner dessa maneira, a instalação de pacotes e a compilação são executadas em um estado completamente isolado das credenciais do sistema do notebook principal, bloqueando na raiz qualquer caminho de vazamento de ativos corporativos.