Skip to content

Compromiso da estación de traballo do programador: dependencia maliciosa ou resposta á extensión IDE

Os números de emerxencia varían segundo o país. Esta páxina usa 911, o número dos Estados Unidos e Canadá. Moitos outros países usan 112, 999 ou outro número. Busca o número do teu país.

Descubrindo que un paquete de software que acaba de instalar npm install, pip install, cargo build, gem install, ou go get, ou unha extensión de Visual Studio Code, Cursor ou IDE de JetBrains recentemente actualizada, é un typosquat malicioso, unha carga útil de confusión de dependencias ou unha versión upstream secuestrada representa unha emerxencia de infraestrutura crítica. A diferenza dos ordenadores de consumo estándar, un enxeñeiro de software, un arquitecto de DevOps ou unha estación de traballo de científico de datos posúe claves criptográficas directas para ambientes de produción na nube, repositorios de código fonte, rexistros de contedores, canalizacións CI/CD e bases de datos de clientes. Cando un malicioso preinstall ou postinstall guión dentro package.json, un armado setup.py nunha roda Python, ou comprometida .vsix execútase no seu portátil, execútase cos seus privilexios de usuario completos e colleita inmediatamente -/.aws/credentials, -/.ssh/id_ed25519, -/.npmrc, -/.pypirc, -/.kube/config, local .env ficheiros, macOS Keychain ou Linux libsecret entradas e cookies de sesión activas do navegador en segundos.

Se acabas de decatarte de que executaches unha dependencia maliciosa de código aberto, clonaches e construíches un repositorio armado (como un proxecto de entrevista técnica falso a partir dunha estafa de reclutador) ou instalaches unha extensión IDE trojanizada, cada segundo que a túa máquina permanece conectada á rede permite que a carga útil cambie á túa nube corporativa ou publique gusanos de autopropagación usando o teu paquete de rexistros. Se o ataque implica extorsión, ameazas físicas ou interrupción crítica da infraestrutura pública, chame ao número de emerxencia local (911 nos Estados Unidos e Canadá, 112 en toda a Unión Europea, 999 no Reino Unido) ou consulte o noso internacional números de emerxencia directorio. Siga estes procedementos de contención, triaxe forense e rotación de claves criptográficas inmediatamente.

Fai isto agora

  1. Corta todas as conexións de rede na estación de traballo do programador inmediatamente (desactiva o Wi-Fi, desconecta Ethernet e elimina os túneles VPN ou SSH activos), pero NON apagues nin reinicies a máquina aínda: Desconectar Ethernet e desactivar a Wi-Fi impide que un shell inverso activo, unha baliza C2 ou un gusano automatizado utilicen os teus tokens locais para empurrar buckets adicionais ou filtrados maliciosos. Manteña a máquina acendida en estado sen conexión (ou suspéndea só despois de capturar listas de procesos volátiles) para que poida inspeccionar os procesos fillos en execución, os sockets de rede abertas, o historial de shell e exactamente cales. .env e os ficheiros de credenciais residían no disco no momento da execución.
  2. Utiliza un dispositivo separado e limpo (como o teu teléfono intelixente con datos móbiles ou un portátil sen tocar) para notificar ao teu Centro de operacións de seguranza (SOC) e revogar as túas sesións de inicio de sesión único (SSO) e Cloud IAM: nunca inicies sesión en AWS, GCP, Azure, GitHub ou Okta desde a estación de traballo infectada para rotar as teclas. Se un ladrón residente na memoria, unha extensión IDE maliciosa ou un gancho de shell está observando o teu terminal e navegador, calquera novo token que xeras nesa máquina captúrase ao instante.
  3. Revoga e xira os teus tokens de programador de alto radio de explosión por estrita orde de prioridade nos primeiros 15 minutos:
  4. Prioridade 1 (Cloud e Kubernetes): desactiva todas as claves de acceso AWS IAM locais (AKIA...), revoque as credenciais predeterminadas da aplicación de Google Cloud (gcloud auth application-default revoke), invalidar tokens de Azure CLI (az account clear + Revogación da sesión Entra ID) e rota Kubernetes kubeconfig certificados de cliente ou tokens de conta de servizo.
  5. Prioridade 2 (código fonte e CI/CD): elimina todas as chaves públicas SSH de GitHub, GitLab e Bitbucket, tokens de acceso persoal (ghp_..., github_pat_..., glpat-...), e tokens de CLI de OAuth (-/.config/gh/hosts.yml), e inspeccione a configuración do webhook do repositorio e os segredos de GitHub Actions / GitLab CI.
  6. Prioridade 3 (rexistros e contedores de paquetes): revogue a automatización de npm e publique tokens (-/.npmrc), tokens da API PyPI (-/.pypirc), Tokens de inicio de sesión Docker Hub / GHCR / ECR (-/.docker/config.json), e fichas de Terraform Cloud (-/.terraform.d/credentials.tfrc.json).
  7. Comprobe npm, PyPI, Cargo e GitHub AGORA MESMO para verificar que o malware non usou xa os seus tokens locais para publicar unha versión infectada por gusanos dos seus propios paquetes ou enviar confirmacións maliciosas: cargas útiles modernas da cadea de subministración (como o ua-parser-js, coa, rc, ctx, lottie-player, e ultralytics compromisos) analizan automaticamente as do programador vítima -/.npmrc, -/.pypirc, e -/.gitconfig para publicar inmediatamente versións de parches con porta traseira de cada paquete interno ou de código aberto que manteña o programador, ou crear fluxos de traballo ocultos de GitHub Actions nos repositorios do programador.
  8. Escanear todos os directorios de proxectos na estación de traballo para crear un inventario completo de expostos .env ficheiros, cadeas de conexión de base de datos e claves API codificadas: antes de borrar a estación de traballo, execute un script sen conexión na máquina illada para listar cada .env, .env.local, terraform.tfstate, e application.yml ficheiro no seu disco duro para que poida xirar todas as credenciais de segredo de terceiros (Stripe, Twilio, SendGrid, OpenAI, Anthropic, Datadog, Slack, Postgres, MongoDB e Redis) que fose lexible pola súa conta de usuario.
  9. Termina todas as sesións do navegador e as conexións de carteira de hardware: debido a que os compromisos dos desenvolvedores adoitan implementar roubos de información sobre produtos básicos (como Lumma, RedLine ou Atomic macOS Stealer) xunto aos recolectores de credenciais específicos do programador, siga o noso Secuestro de cookies de sesión e guía de revogación de tokens de infostealer e, se desenvolves Web3 ou tes activos dixitais, executa o noso Guía de compromiso de frase semente e drenaxe de carteira de criptomonedas.

Danger

Por que correr npm uninstall <package> ou pip uninstall <package> NON limpa a túa estación de traballo: No Node.js (npm, yarn, pnpm) e Python (pip) ecosistemas, o código malicioso case nunca espera ata ti import ou require() a biblioteca no código da aplicación. Pola contra, os atacantes colocan a carga útil dentro dos ganchos do ciclo de vida do paquete (preinstall, install, ou postinstall en package.json, ou execución de nivel superior dentro setup.py durante a construción da roda de distribución de orixe). No momento en que presionaches Enter on npm install ou pip install, o script shell arbitrario do atacante ou o binario executado no seu sistema operativo, copiou o seu -/.ssh, -/.aws, e .env ficheiros a un servidor externo e moitas veces inxectaba unha porta traseira persistente -/.bashrc, -/.zshrc, crontab, ou -/Library/LaunchAgents. A desinstalación do paquete despois só elimina o cartafol que hai dentro node_modules ou site-packages mentres deixas as chaves roubadas nas mans do atacante e o mecanismo de persistencia en execución no teu SO.


Árbore de decisións: clasificación do compromiso da cadea de subministración da estación de traballo do programador

Use este fluxo de traballo de resposta a incidentes para conter o raio da explosión tanto no seu contorno de desenvolvemento persoal como na infraestrutura corporativa de produción:

flowchart TD
    Detect["Executouse un paquete npm/PyPI/Cargo malicioso, extensión IDE troiana ou repo de recrutamento falso."] --> Isolate["PASO 1: Desconecte inmediatamente a estación de traballo Wi-Fi e Ethernet (manteña a máquina acendida para a clasificación sen conexión)"]

    Isolate --> ScopeCheck{"Ocorreu a execución no sistema operativo anfitrión ou dentro do contedor/VM illado?"}
    ScopeCheck -->|"Sistema operativo anfitrión (Mac/Linux/Windows/WSL2)"| FullCompromise["Supón que o 100 % do directorio de inicio (-/.aws, -/.ssh, -/.npmrc, .env, cookies do navegador) foi exfiltrado"]
    ScopeCheck -->|"DevContainer / Docker"| MountCheck["Comprobe os montaxes de volume (-v -/.ssh, -v -/.aws, Docker Socket /var/run/docker.sock ou Host Network)"]
    MountCheck --> FullCompromise

    FullCompromise --> CleanDevice["PASO 2: Desde un dispositivo limpo separado, alerta SOC e revoga Cloud IAM, SSO, GitHub/GitLab e tokens de rexistro"]

    CleanDevice --> WormCheck["PASO 3: auditar as confirmacións de GitHub, os fluxos de traballo CI/CD e as versións publicadas de npm/PyPI para a propagación automatizada de vermes"]

    WormCheck --> OfflineAudit["PASO 4: na estación de traballo sen conexión, inventaria todos os ficheiros .env, ficheiros de estado de Terraform e portas traseiras de persistencia"]

    OfflineAudit --> RotateEnv["PASO 5: Xire cada contrasinal da base de datos, segredo de webhook, chave de sinatura GPG e chave API que se atopen nos ficheiros .env/State"]

    RotateEnv --> RebuildOS["PASO 6: Limpar a estación de traballo mediante Clean OS Reinstall -> Aplicar chaves SSH respaldadas por hardware, OIDC e --ignore-scripts"]

Comprender como se executan os vectores da cadea de subministración e IDE do programador

Os ataques modernos contra enxeñeiros de software teñen como obxectivo catro superficies de execución distintas nunha estación de traballo. Identificar que vector golpeou a túa máquina indícanos a que privilexios e rutas de ficheiros accedeu a carga útil:

1. Ganchos de ciclo de vida de paquetes maliciosos (npm, pnpm, yarn, pip, cargo, gem)

  • Node.js (package.json scripts): por defecto, en execución npm install executa automaticamente calquera comando de shell definido no ficheiro "preinstall", "install", ou "postinstall" campos de package.json, non só para o paquete de nivel superior que escribiu, senón para todas as dependencias transitivas da árbore. Os atacantes usan ocupación en cuclillas (por exemplo, reqeusts, crossenv, lodahs), confusión de dependencia (publicar un paquete público en npm ou PyPI co mesmo nome e un número de versión superior, como 99.99.9, como paquete privado interno da túa empresa), ou adquisicións de contas de mantedores para deslizar unha única liña como "postinstall": "node index.js" nun paquete.
  • Python (setup.py e .pth ficheiros): Cando pip instala unha distribución de orixe (sdist .tar.gz), executa setup.py con privilexios completos de intérprete de Python. Incluso ao instalar rodas binarias precompiladas (.whl) que non executan setup.py durante a instalación, os atacantes inclúen ** maliciosos.pth (configuración do camiño) ficheiros** caídos directamente en site-packages/. Calquera liña dentro de a .pth ficheiro que comeza por import é executado automaticamente polo intérprete de Python cada vez python comeza nese sistema.
  • ** óxido (build.rs) e Go**: en Rust, Cargo compila e execútase automaticamente build.rs non só durante cargo build ou cargo run, pero inmediatamente cando rust-analyzer (dentro de VS Code ou IntelliJ) abre un cartafol do proxecto para indexar tipos. Simplemente abrindo un repositorio de Rust clonado no teu IDE con rust-analyzer enabled executa código arbitrario dentro build.rs antes de escribir un comando de terminal.

2. Extensións IDE maliciosas ou secuestradas (VS Code Marketplace, OpenVSX, JetBrains)

  • Extensións de Visual Studio Code, Cursor, Windsurf e VSCodium (.vsix) execútase no proceso principal de Node.js Extension Host na súa estación de traballo con sandboxing cero. Calquera extensión instalada ten acceso completo de lectura/escritura a todo o seu sistema de ficheiros, pode xerar procesos fillos silenciosos (child_process.exec), pode ler todos os búfers de editor abertos e .env ficheiro e pode conectar o seu terminal integrado.
  • Os actores de ameazas publican habitualmente extensións de temas falsos (Darcula Official), asistentes de codificación de intelixencia artificial falsificados ou extensións linter/Prettier falsificadas que descargan silenciosamente un infostealer de segunda etapa ou un shell inverso no momento en que se inicia o IDE.

3. Repositorios Git armados e execución automática do espazo de traballo IDE (trampas ("Fake Recruiter / Take-Home Test")

  • Grupos patrocinados polo estado de Corea do Norte (Contagious Interview / Lazarus Group) e os actores de ameazas centrados nas criptográficos achéganse rutineiramente aos desenvolvedores en LinkedIn, Upwork ou GitHub facéndose pasar por recrutadores ou CTOs que ofrecen roles remotos ben remunerados. Pídenlle ao programador que clone un repositorio de Bitbucket ou GitHub para unha "avaliación de depuración de 15 minutos" ou unha "revisión de MVP de xogos Web3".
  • Estes repositorios conteñen trampas de execución ocultas que se activan cando se abren nun IDE ou durante a compilación:
  • .vscode/tasks.json con "runOn": "folderOpen": executa automaticamente un script de shell en segundo plano no momento en que fai clic en "Si, confío nos autores" en VS Code.
  • Malicioso .git/hooks/ ou .gitmodules: Explota a configuración do submódulo Git ou scripts de compilación (Makefile, webpack.config.js, next.config.js, vite.config.ts) que cargan cargas útiles de JavaScript ofuscadas (a miúdo acolchadas con miles de espazos fóra da pantalla para ocultarse na columna 2.000+) chamando a un servidor C2 externo.

Fase 1: completa a matriz de rotación secreta e credenciais do programador

Usando un portátil ou teléfono intelixente secundario limpo, traballa de forma sistemática neste inventario de credenciais de programador de 12 puntos. Supoña que calquera ficheiro lexible pola súa conta de usuario do sistema operativo non root (chmod 600 ou 644 propiedade do teu usuario) cargouse no servidor do atacante dentro dos 3 segundos seguintes á execución da carga útil.

Categoría de credenciais Rutas de ficheiros locais exactas recollidas na estación de traballo Acción obrigatoria de revogación e rotación (desde un dispositivo limpo)
1. AWS IAM e SSO -/.aws/credentials
-/.aws/config
-/.aws/sso/cache/*.json
-/.aws/cli/cache/*.json
1. En AWS IAM Console, inmediatamente Desactive e elimine todas as claves de acceso estáticas (AKIA...) almacenado nese portátil.
2. En AWS IAM Identity Center (SSO), revogue as sesións de usuarios activas e elimine os tokens de dispositivos cliente OIDC rexistrados.
3. Auditoría AWS CloudTrail para GetCallerIdentity, CreateUser, CreateAccessKey, AssumeRole, ListBuckets, e SecretsManager:GetSecretValue chamadas procedentes de IP ou axentes de usuario pouco habituais (Boto3, aws-cli, Go-http-client).
2. Google Cloud (GCP) e Firebase -/.config/gcloud/credentials.db
-/.config/gcloud/access_tokens.db
-/.config/gcloud/application_default_credentials.json
-/.config/configstore/firebase-tools.json
*-service-account.json
1. Ir a myaccount.google.com/permissions e revoga o acceso para Google Cloud SDK e Firebase CLI.
2. En Consola GCP > IAM e administración > Contas de servizo, elimine calquera chave JSON da conta de servizo (private_key_id) que se descargou no disco duro da estación de traballo.
3. Inspeccione Rexistros de auditoría de nube para ver as conexións IAM non autorizadas ou a creación de Compute Engine.
3. Microsoft Azure e ID de entrada -/.azure/msal_token_cache.bin
-/.azure/accessTokens.json
-/.azure/azureProfile.json
1. Fai unha execución de Entra ID Admin Revoke-MgUserSignInSession -UserId <your-user-id> para invalidar todas as fichas de actualización e as fichas de actualización primarias (PRT).
2. Elimine calquera segredo ou certificado de cliente principal do servizo almacenado localmente.
4. Kubernetes e Helm -/.kube/config
-/.kube/cache/
-/.config/helm/registry/config.json
1. Se -/.kube/config contiña certificados de cliente estáticos (client-certificate-data / client-key-data) ou tokens de portador de ServiceAccount de longa duración, revogue o certificado a través da súa CA de clúster (CSR / eliminación de RBAC) ou borrar e recrear ServiceAccount segredo inmediatamente.
2. Audite os rexistros de auditoría do servidor API de Kubernetes exec, pods, ou secrets listar/obter verbos.
5. GitHub, GitLab e Bitbucket -/.ssh/id_ed25519, -/.ssh/id_rsa
-/.config/gh/hosts.yml
-/.git-credentials, -/.netrc
-/.gitconfig
1. Ir a github.com/settings/keys (e equivalentes de GitLab/Bitbucket) e Eliminar a chave pública SSH e a chave de sinatura de commit GPG/SSH da máquina infectada.
2. Ir a github.com/settings/tokens e github.com/settings/applications para revogar todos os tokens de acceso persoal (ghp_, github_pat_), aplicacións OAuth (GitHub CLI, VS Code, Git Credential Manager), e sesións web activas.
3. Comprobe Rexistro de seguranza (github.com/settings/security-log) para repo.clone, org.Invite_member, ou hook.create.
6. GPG e chaves de sinatura de código -/.gnupg/private-keys-v1.d/
-/Library/Keychains/login.keychain-db (ID de programador de Apple / .p12)
1. Se a túa clave privada GPG almacenouse no disco sen unha tarxeta intelixente de hardware (YubiKey OpenPGP) e a frase de acceso foi almacenada na caché gpg-agent ou escrito recentemente, xera e publica un Certificado de revogación GPG inmediatamente e elimina a chave GPG de GitHub/GitLab.
2. Revoga calquera programador de Apple exportado .p12 ou Android Keystore .jks certificados de sinatura de código almacenados na máquina.
7. Rexistros de paquetes (npm, PyPI, Cargo, RubyGems, NuGet) -/.npmrc (_authToken=...)
-/.pypirc
-/.cargo/credentials.toml
-/.gem/credentials
1. Inicia sesión en npmjs.com > Fichas de acceso, pypi.org > Configuración da conta > Fichas API, crates.io > Configuración da conta > Fichas API e rubygems.org e Revoga todos os tokens activos inmediatamente.
2. Avisa os teus paquetes publicados (consulta a Fase 2 a continuación) para confirmar que o atacante non impulsou unha versión con porta traseira nas últimas horas.
8. Docker e rexistros de contedores -/.docker/config.json (Base 64 auths para Docker Hub, GHCR, ECR, GCR, Quay) 1. Lembra que "auth" en -/.docker/config.json (cando non se usa credsStore: osxkeychain ou wincred) é só Base64 sen cifrar username:password_or_token.
2. Revoga os tokens de acceso persoal en Docker Hub (hub.docker.com/settings/security), GitHub Container Registry e Quay.io.
9. Infraestrutura como código (Terraform / Pulumi / Ansible Vault) -/.terraform.d/credentials.tfrc.json
**/terraform.tfstate (Arquivos de estado local)
-/.pulumi/credentials.json
-/.vault-token
1. Revoga os tokens da API de usuario de Terraform Cloud / Enterprise e os tokens de HashiCorp Vault.
2. CRÍTICO: calquera local terraform.tfstate O ficheiro do teu disco contén contrasinais de texto sinxelo, credenciais mestras de RDS, chaves TLS privadas e claves secretas de IAM para cada recurso xestionado por ese estado. Xire todos os segredos referenciados dentro de local .tfstate ficheiros.
10. Bases de datos e historias da CLI de almacenamento en caché -/.psql_history, -/.pgpass
-/.mysql_history, -/.my.cnf
-/.rediscli_history
-/.mongodb/mongosh/
Configuración de DBeaver / TablePlus / DataGrip
1. Os xestores de bases de datos da GUI (TablePlus, DBeaver, DataGrip, Postico, pgAdmin, MongoDB Compass) almacenan contrasinais de bases de datos cifrados ou ofuscados localmente que os ladróns descifran habitualmente.
2. Xire os contrasinais dos usuarios da base de datos para calquera base de datos de produción ou de produción accesible a través de VPN, bastión ou IP pública desde a súa estación de traballo.
11. Aplicación .env Ficheiros e chaves SaaS de terceiros **/.env, **/.env.local, **/.env.production, **/.env.development Xire todas as claves API almacenadas no proxecto local .env ficheiros: Stripe (sk_live_...), OpenAI (sk-...), antrópico (sk-ant-...), Twilio, SendGrid, AWS SES, Slack Bot Tokens (xoxb-...), Fichas de Discord Bot, Datadog, Sentry, Supabase (service_role), Firebase Admin e segredos de sinatura de JWT.
12. Hosts coñecidos SSH e servidores Bastion Jump -/.ssh/config
-/.ssh/known_hosts
-/.zsh_history, -/.bash_history
Os atacantes analizan inmediatamente -/.ssh/config e -/.zsh_history para atopar cada IP do servidor interno, host bastión e nome de usuario aos que se conecte e, a continuación, use o seu roubado -/.ssh/id_ed25519 clave para iniciar sesión directamente neses servidores. Elimina a túa antiga chave pública de -/.ssh/authorized_keys en cada servidor Linux remoto e comproba /var/log/auth.log neses servidores para inicios de sesión SSH non autorizados.

Fase 2: Comprobación da propagación automatizada de vermes da cadea de subministración (Rexistros de paquetes, CI/CD e GitHub)

A diferenza do malware xenérico, as cargas útiles dirixidas aos desenvolvedores están programadas especificamente para propagarse pola cadea de subministración de software en segundos despois de aterrizar na túa estación de traballo. Antes de volver a limpar o teu portátil, utiliza o teu dispositivo limpo para verificar que as credenciais roubadas non se usaron xa para infectar ao teu equipo ou aos usuarios posteriores:

  1. Audit os teus repositorios GitHub/GitLab para as portas traseiras silenciosas e fluxos de traballo maliciosos:
  2. Comprobar .github/workflows/*.yml en todos os repositorios aos que tes acceso de escritura: gusanos recentes da cadea de subministración (Shai-Hulud, tj-actions/changed-files compromisos, e ultralytics exploits) usan automaticamente tokens de programador roubados para cometer un fluxo de traballo malicioso de GitHub Actions ou modificar un fluxo de traballo existente para volcar ${{ toJSON(secrets) }} (exfiltrando os segredos de implementación de produción da túa organización dos corredores de GitHub Actions).
  3. Verifica as confirmacións recentes polo autor e a marca de tempo do committer: Teña en conta que calquera pode forxar un nome de autor de Git e unha marca de tempo (git commit --date="..." --author="..."). En GitHub, inspecciona os Eventos push no repositorio Vista de actividade ou organización Rexistro de auditoría (repo.push), que rexistran a marca de tempo real do servidor e o token de autenticación exacto (oauth_application_id ou ssh_key_fingerprint) que impulsou o código.
  4. Consulta os webhooks do repositorio, as claves de implementación e os colaboradores: mira en Configuración > Webhooks, Configuración > Implementar chaves e Configuración > Colaboradores e equipos nos teus repositorios para asegurarte de que o atacante non engade unha chave de implementación de lectura/escritura persistente ou un webhook que apunte a un servidor externo.
  5. Audit npm, PyPI, Cargo e Docker Hub para lanzamentos de paquetes non autorizados:
  6. Se es mantedor ou colaborador de calquera paquete público ou privado en npm, PyPI, RubyGems ou Crates.io, consulta a pestana Versións/Historial de lanzamentos para cada paquete da túa conta.
  7. Se unha versión do parche (por exemplo, 1.4.2 despois da súa última liberación lexítima 1.4.1) publicouse dentro do prazo de compromiso da túa estación de traballo, desaprobar ou tirar esa versión inmediatamente (npm deprecate <pkg>@<version> "CRITICAL: Compromised version, do not use" ou tira en PyPI) e ponte en contacto con npm Support (security@npmjs.com / Seguridade GitHub) ou Seguridade PyPI (security@pypi.org) para eliminar o artefacto malicioso e poñer en corentena as versións afectadas.
  8. Comprobar a exfiltración secreta de TruffleHog/Git Clone:
  9. Os ladróns da cadea de subministración chaman con frecuencia á API de GitHub/GitLab usando o token roubado para clonar todos os depósitos organizativos privados aos que tes acceso e executar escáneres secretos automatizados (TruffleHog ou Gitleaks) contra todo o historial de compromisos da túa empresa. Se algunha vez a túa organización comprometeu accidentalmente un segredo no historial de Git dun repositorio privado sen rotalo, rota eses segredos históricos agora.

Fase 3: Triaxe forense fóra de liña na estación de traballo comprometida

Coa túa estación de traballo completamente desconectada da wifi e Ethernet, abre unha ventá de terminal para realizar a clasificación sen conexión. O teu obxectivo é dobre: (A) localiza todos .env e ficheiro de configuración no disco para que saibas que segredos queres rotar e (B) captura evidencias do que realmente executou o paquete ou extensión malicioso antes de borrar o sistema operativo.

Paso 1: Inventaria todos os expostos .env, chave privada e ficheiro de estado no seu disco

Executa este comando de só lectura na túa estación de traballo macOS, Linux ou WSL2 sen conexión para xerar unha lista de verificación completa de todos os ficheiros locais que conteñan segredos que o malware puido ler:

# Create an offline audit list of all .env files, Terraform states, kubeconfigs, and private keys in your home directory:
find ~ -maxdepth 5 \( \
    -name ".env" -o \
    -name ".env.*" -o \
    -name "*.tfstate" -o \
    -name "*.tfstate.backup" -o \
    -name "*.pem" -o \
    -name "*.key" -o \
    -name "*.p12" -o \
    -name "*.pfx" -o \
    -name "*service-account*.json" -o \
    -name "credentials.json" -o \
    -name ".npmrc" -o \
    -name ".pypirc" -o \
    -name ".netrc" \
\) -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/Library/Caches/*" 2>/dev/null > ~/exposed_secrets_inventory.txt

cat ~/exposed_secrets_inventory.txt

Revisión -/exposed_secrets_inventory.txt liña por liña e abrir cada unha .env ou .tfstate ficheiro fóra de liña para que poida rotar cada clave de API, contrasinal da base de datos e segredo de webhook que aparecen no seu dispositivo limpo.

Paso 2: inspeccione o que se executou o paquete malicioso ou a extensión IDE

Antes de eliminar o cartafol ofensivo, inspeccione a carga útil exacta e comprobe onde instalou a persistencia no seu sistema operativo:

# 1. Inspect package.json lifecycle scripts in the suspect project and its node_modules:
grep -rnE '"(preinstall|install|postinstall|prepublish|prepare)"' ./package.json ./node_modules/*/package.json ./node_modules/@*/*/package.json 2>/dev/null

# 2. Check Python site-packages for malicious .pth startup hook files:
find . -path "*/site-packages/*.pth" -exec head -n 20 {} + 2>/dev/null

# 3. Inspect recently installed or modified VS Code / Cursor / Windsurf Extensions:
ls -lt ~/.vscode/extensions/ ~/.cursor/extensions/ ~/.windsurf/extensions/ 2>/dev/null | head -n 30

# 4. Check for persistence injected into your Shell RC profiles and Git global hooks:
tail -n 30 ~/.zshrc ~/.bashrc ~/.bash_profile ~/.zprofile ~/.profile 2>/dev/null
git config --global --list | grep -E "core.hooksPath|alias|credential|filter"

Paso 3: busca a persistencia a nivel de SO eliminada polo malware do programador (macOS, Linux e Windows)

As dependencias maliciosas e os repositorios de "reclutadores falsos" adoitan soltar axentes persistentes en segundo plano disfrazados de actualizadores do sistema, daemons Node ou indexadores Spotlight:

  • En Apple macOS:
    # 1. Check user and system LaunchAgents / LaunchDaemons for recently added .plist files:
    ls -laht ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
    
    # 2. Check active cron jobs and running background node/python/curl/nohup processes:
    crontab -l
    ps aux | grep -iE "node|python|osascript|curl|wget|nc|bash -i|/tmp/|/var/tmp/|Library/Application Support"
    
  • En Linux/Ubuntu/Fedora/WSL2:
    # 1. Check user systemd services, cron jobs, and SSH authorized_keys:
    ls -la ~/.config/systemd/user/ /etc/systemd/system/
    crontab -l
    cat ~/.ssh/authorized_keys
    
    # 2. Check running processes executing out of /tmp, /dev/shm, or ~/.cache:
    ls -la /proc/*/exe 2>/dev/null | grep -E "/tmp/|/dev/shm/|\.cache|\.local"
    
  • En Windows (nativo ou anfitrión de WSL2):
  • Lembra que un script npm ou Python malicioso que se executa dentro de WSL2 (subsistema de Windows para Linux) pode acceder directamente ao teu host Windows completo C:\ conducir por /mnt/c/Users/<username>/ e pode invocar powershell.exe ou cmd.exe directamente desde dentro do shell de Linux para infectar o Rexistro de host de Windows (HKCU:\Software\Microsoft\Windows\CurrentVersion\Run), Tarefas programadas e Chrome/Edge Cookies bases de datos.
  • Executa a auditoría de persistencia completa de Windows PowerShell no noso Guía de secuestro de cookies de sesión e infostealer e o noso guía de infección de malware, ransomware e spyware.

Fase 4: Por que debes limpar e reconstruír a estación de traballo do programador

Aínda que atopes e elimines o malicioso node_modules cartafol, o .vsix extensión, e un canalla -/Library/LaunchAgents plist, nunca deberías seguir usando unha estación de traballo de programador comprometida para a enxeñaría de produción sen realizar unha limpeza e reinstalación limpas do SO.

As cargas útiles sofisticadas dirixidas a desenvolvedores modifican os ficheiros binarios ou de configuración lexítimos existentes no seu sistema que ningún escáner antivirus sinala como maliciosos: 1. ** Binarios CLI locais troyanizados (git, ssh, sudo, aws, kubectl, docker): non se pode sobrescribir unha carga útil que se executa na túa conta de usuario /usr/bin/ssh sen sudo, polo que, en cambio, solta un script de envoltura en -/.local/bin/ssh,-/bin/git** ou -/bin/sudo e antepón ese directorio ao teu PATH. A próxima vez que escriba sudo ou ssh -i despois de volver conectarse a Internet, o envoltorio intercepta silenciosamente o teu contrasinal ou frase de acceso e envíallo ao atacante antes de chamar ao binario real. 2. Cachés de paquetes locais infectados (-/.npm/_cacache, -/.cache/pip, -/.cargo/registry, -/Library/Caches/pnpm): O malware pode envelenar os tarballs almacenados na caché dentro da túa caché do xestor de paquetes local, de xeito que mesmo cando instales un paquete limpo e lexítimo a próxima semana, o teu xestor de paquetes descomprime o tarball con porta traseira da túa caché local. 3. Ficheiros IDE Core modificados (workbench.desktop.main.js): determinadas cargas útiles de VS Code e Cursor parchean directamente o Electron asar arquivo ou workbench.desktop.main.js dentro do paquete de aplicacións IDE para que a porta traseira sobreviva eliminando todas as extensións.

Fai unha copia de seguranza só do código fonte puro (verificado mediante git status e git diff nunha máquina limpa) e documentos persoais e, a continuación, realice unha borrar macOS limpo de todo o contido e configuración/Restaurar DFU, unha instalación USB limpa de Linux ou unha instalación USB limpa de Windows 11.


Endurece a túa nova estación de traballo para desenvolvedores contra futuros ataques á cadea de subministración

Cando configures a túa estación de traballo de programador recentemente borrada, substitúe os ficheiros de texto plano estáticos do teu directorio de inicio por fluxos de traballo efémeros e sandbox respaldados por hardware para que, aínda que se execute unha dependencia maliciosa no futuro, haxa cero segredos estáticos no disco para que poida roubar:

1. Desactive a execución automática de script de ciclo de vida nos xestores de paquetes

Configurar npm, pnpm, yarn, e pip polo que as dependencias non fiables non poden executar silenciosamente scripts de shell durante a instalación: - Node.js (npm / yarn / pnpm):

# Globally disable automatic preinstall/postinstall script execution in npm:
npm config set ignore-scripts true
(Nota: pnpm v10+ agora desactiva os scripts de compilación do ciclo de vida para as dependencias de forma predeterminada, a non ser que se permita explícitamente a través de pnpm.onlyBuiltDependencies en package.json, facendo pnpm v10+ significativamente máis seguro contra os vermes da cadea de subministración que por defecto npm.) - Python (pip / uv):
# Refuse to run arbitrary setup.py scripts from source distributions (.tar.gz); require binary wheels only:
export PIP_ONLY_BINARY=":all:"
- Ventana de enfriamento/idade mínima de lanzamento: a maioría das versións maliciosas de npm e PyPI detéctanse e elimínanse nun prazo de 4 a 24 horas despois da publicación. Configure o seu xestor de paquetes ou proxy de artefactos (como npm config set before, pnpm minimumReleaseAge, ou Socket.dev/Firewall Artifactory) para rexeitar as versións dos paquetes publicadas nas últimas 48 a 72 horas.

2. Elimina o texto plano -/.ssh/id_ed25519, -/.aws/credentials, e .env Ficheiros do disco

  • Mover as chaves SSH a unha YubiKey de hardware (ed25519-sk) ou Enclave seguro/axente biométrico:
  • Nunca deixe un código sen cifrar ou sen contrasinal -/.ssh/id_ed25519 arquivo no disco. Ou xerar unha chave SSH FIDO2 residente no hardware (ssh-keygen -t ed25519-sk -O verify-required) nunha YubiKey física (que require que o teu dedo toque o contacto metálico para cada git push ou ssh conexión), ou almacena as túas claves SSH dentro do 1Password SSH Agent/Segredo (macOS Secure Enclave) onde a chave privada nunca existe como ficheiro en -/.ssh/ e cada sinatura solicita Touch ID / Windows Hello.
  • Substituír estática -/.aws/credentials (AKIA...) con SSO de curta duración (aws sso login ou aws-vault):
  • Eliminar todas as claves permanentes de acceso de usuario de IAM (AKIA...). Use AWS IAM Identity Center (aws sso login) con sesións curtas (de 1 a 4 horas) ou envolver credenciais dentro aws-vault apoiado por macOS Keychain / Windows Credential Manager con indicacións biométricas.
  • ** Substitúe o texto sen formato .env Ficheiros con inxección secreta en tempo de execución (1Password CLI op run, Doppler, ou aws-vault)**:
  • En vez de almacenar STRIPE_SECRET_KEY=sk_live_... nun texto plano .env arquivo que calquera node_modules guión pode fs.readFileSync('.env'), almacena referencias como STRIPE_SECRET_KEY="op://Dev-Vault/Stripe/secret_key" e inicia o teu servidor de desenvolvemento local a través de op run --env-file=".env.template" -- npm run dev despois de autenticarse con Touch ID.
  • Utiliza Publicación de confianza (OIDC) en lugar de Longa vida -/.npmrc e -/.pypirc Fichas:
  • Nunca garde un token capaz de publicar dentro -/.npmrc ou -/.pypirc no teu portátil. Tanto PyPI como npm (a través de Provenance/OIDC) permítenche publicar paquetes exclusivamente de GitHub Actions/GitLab CI Trusted Publishers illados usando tokens de OpenID Connect (OIDC) de curta duración, o que significa que nunca hai ningún token de publicación no portátil de calquera mantedor.

3. Illa os repositorios non fiables e crea scripts dentro de DevContainers ou máquinas virtuales reforzadas

  • Nunca clones e executes unha "Avaliación de Recruiter Take-Home", un proxecto de código aberto descoñecido ou un repositorio de recompensas directamente no teu sistema operativo anfitrión:
  • Executa proxectos descoñecidos dentro dun Espazo de códigos GitHub, unha máquina virtual de nube desbotable ou un Docker DevContainer local que NON monta o directorio de inicio do teu host (-), fai NON montar /var/run/docker.sock, e só pasa un token Git de só lectura con alcance se é necesario.
  • Audit VS Code / Cursor Extensions and Disable Auto-Updates for Unverified Publishers:
  • Lembra que Cursor, Windsurf e VSCodium extraen extensións do Rexistro OpenVSX (open-vsx.org) en lugar do Visual Studio Marketplace oficial de Microsoft. Verifica o espazo de nomes do editor exacto e o reconto de instalacións antes de instalar calquera extensión, mantén a túa lista de extensións instaladas mínima e desinstala as extensións que xa non utilizas activamente.

Preguntas frecuentes

Fai correr npm install --ignore-scripts protexeme completamente dun paquete npm malicioso?

Correndo npm install --ignore-scripts bloquea o vector de ataque máis común á cadea de subministración: execución automática de preinstalar, instalar, e postinstalación comandos de shell definidos dentro package.json no momento da instalación. Non obstante, non o protexe unha vez que executas o código JavaScript do paquete (por exemplo, cando executas npm executar dev, proba npm, broma, paquete web, ou vite, ou cando o complemento ESLint/TypeScript do teu IDE carga un complemento malicioso desde módulos_nodos). Debido a que Node.js non ten sistema de ficheiros en tempo de execución nin sandbox de rede por defecto, calquera código importado durante o paso de compilación ou proba aínda pode ler -/.aws e -/.ssh a menos que illes a compilación dentro dun contedor ou uses o modelo de permisos experimental de Node (nodo --permiso).

Abrín un repositorio sospeitoso en VS Code dun reclutador en LinkedIn e fixen clic en "Si, confío nos autores" antes de darme conta de que era unha estafa. O código executouse aínda que nunca corra npm install?

Si, debes asumir que o código arbitrario se executou exactamente no momento en que premeches "Si, confío nos autores". En Visual Studio Code e Cursor, a concesión de Workspace Trust permite inmediatamente o repositorio .vscode/tasks.json ficheiro para executar tarefas de shell en segundo plano configuradas "runOn": "carpeta aberta", permite definir o espazo de traballo .vscode/settings.json para apuntar servidores de linguaxe (como Python, TypeScript, ESLint ou Rust Analyzer) a rutas executables maliciosas dentro do cartafol do repositorio e activa a execución automática de construír.rs en proxectos Rust. Desconecte a máquina da rede inmediatamente e siga a Fase 1 para rotar todas as credenciais.

Se o paquete malicioso npm ou PyPI executouse nun contenedor Docker ou DevContainer, o meu ordenador portátil Mac ou Windows está seguro?

Depende totalmente de que montaxes de volume, variables de ambiente e sockets se pasaron a ese contenedor. Modelos estándar de DevContainer e locais docker-compose.yml as configuracións adoitan reenviar automaticamente o teu host SSH_AUTH_SOCK (permitindo que o malware dentro do contedor use as claves SSH do teu host para conectarse a servidores remotos ou enviar a GitHub), bind-mount -/.aws, -/.gitconfig, ou o teu espazo de traballo .env ficheiros ou monte o socket Docker do host (/var/run/docker.sock), que outorga acceso instantáneo de root a todo o sistema operativo host. Inspecciona o teu devcontainer.json e inspección do docker monta para ver exactamente que recursos host estaban expostos dentro do contedor.

Como podo comprobar se unha versión do paquete que estou a piques de instalar ten scripts de instalación ocultos ou telemetría ofuscada antes de instalala?

Antes de instalar un paquete npm, PyPI, Go ou Rust descoñecido, inspeccióno Socket.dev ou Deps.dev (por Google Open Source Insights), que analiza de forma estática cada versión para scripts de instalación, solicitudes de rede, acceso ao sistema de ficheiros,eval() ofuscación e cambios de mantedor. Tamén podes correr npm ver scripts no seu terminal para inspeccionar os seus scripts de ciclo de vida sen descargar nin executar o paquete.


Fontes comprobadas

  • Axencia de Seguridade Cibernética e de Infraestruturas (CISA) e Axencia Nacional de Seguridade (NSA) (Estados Unidos): Asegurar a cadea de subministración de software: prácticas recomendadas para desenvolvedores e resposta a dependencias comprometidas.
  • GitHub Security Lab e npm Avisos de seguridade: Respondendo a paquetes npm comprometidos, maliciosos .vscode/tasks.json Trampas de repositorio (Contagious Interview), e mitigacións de exfiltración secreta do fluxo de traballo de GitHub Actions.
  • Autoridade de embalaxe de Python (PyPA) e Seguridade PyPI: Manexo da roda maliciosa .pth Arquivos, setup.py Execución arbitraria e publicación de confianza (OIDC) Directrices de implantación.
  • Open Worldwide Application Security Project (OWASP): Software Supply Chain Security Cheat Sheet & CI/CD Security Top 10 Risks.
  • Centro Nacional de Ciberseguridad (NCSC) (Reino Unido): Defensa dos contornos de desenvolvedores e dos planos de xestión da nube contra a recollida de credenciais dirixida.

Guías relacionadas