원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Узнав об инциденте безопасности, нет времени сидеть поздно ночью и просто гуглить. В мае 2026 года в результате распространения вредоносного расширения Visual Studio Code были взломаны машины разработчиков, а около 3 800 внутренних репозиториев исходного кода компании утекли в сеть. В такой ситуации бессистемное удаление кода или форматирование ноутбука только уничтожит цифровые улики, из-за чего установить причину станет невозможно. Давайте вручную проверим логи выполнения пакетного менеджера, временные метки глобальных CLI и права запущенных процессов, чтобы выяснить, была ли компрометация.
Пакетные менеджеры в процессе установки оставляют транзакционные записи в системном каталоге кэша. npm сбрасывает отладочные логи в папку _logs внутри пути npm config get cache, а pnpm складывает артефакты в pnpm store path. Вредоносные пакеты через скрипты, запускаемые в момент установки, выкачивают переменные окружения или учетные данные наружу, поэтому первым делом нужно поднять историю выполнения жизненного цикла.
Команда для поиска несанкционированного добавления пакетов или выполнения внешних скриптов за последние 14 дней выглядит следующим образом. Откройте терминал и введите ее как есть.
bash NPM_CACHE_DIR=$(npm config get cache) find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
В результатах проверьте, не отрабатывали ли хуки preinstall или postinstall, которые вы не планировали использовать. Это займет всего 3 минуты. Если подозрительных записей о сетевом обмене с внешними URL нет, то от страха прямого заражения на уровне пакетов пока можно перевести дух.
Злоумышленники внедряют вредоносные бинарники в глобальные CLI-инструменты или кэш npx, чтобы закрепиться в системе ноутбука. Извлеките список глобально установленных пакетов и сверьте целостность, сопоставив даты создания и изменения файлов в папке бинарников с системными логами.
bash npm list -g --depth=0 --json ls -lact $(npm config get prefix)/bin/
Если время изменения совпадает с аномальным временным интервалом, извлеките хэш-значения с помощью следующей команды и сравните их.
bash shasum -a 256 $(npm config get prefix)/bin/
Скрипты установки пакетов выполняются с теми же правами, что и аккаунт разработчика. Необходимо завершить фоновые процессы фоновых служб (демонов).
bash ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep lsof -i -P -n | grep -E "node|npm|pnpm"
Если подозрительный процесс связывается с внешним C2-сервером, немедленно перехватите и завершите его.
bash kill -9 [PID] npm config set ignore-scripts true
Излюбленный паттерн атак на цепочку поставок — внедрение изменений в конфигурационные файлы с целью перехвата реестра. Злоумышленник прописывает адрес вредоносного зеркального сервера в файл .npmrc внутри проекта или в глобальные настройки. Подменяя путь к URL скачивания внутри локфайла, он заставляет систему загружать вредоносный tarball при реальной установке, поэтому необходимо досконально проверить все значения конфигурации.
Процедура проверки наличия несанкционированных переопределений в локальных и глобальных настройках выглядит так. Сначала выведите список привязок конфигурации.
bash npm config list pnpm config list
Затем убедитесь, что скоуп внутреннего приватного реестра компании задан корректно.
bash npm config get @company:registry
Также вручную выполните поиск, чтобы узнать, не захардкожены ли адреса внешних зеркал в конфигурационных файлах домашней директории пользователя и корня проекта.
bash grep -Rn "registry" ~/.npmrc ./.npmrc
Пройдя эти три шага, вы сможете за 5 минут определить, были ли зарегистрированы подозрительные адреса зеркал.
Файлы package-lock.json и pnpm-lock.yaml фиксируют исходные URL-адреса для скачивания зависимостей, поэтому их нужно проверить на предмет подмены с помощью регулярных выражений.
bash grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
Если вы используете pnpm, введите следующую команду.
bash grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
Если обнаружен скомпрометированный локфайл, удалите всё и пересоздайте с нуля.
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
Игнорируя выполнение скриптов жизненного цикла и пересобирая дерево зависимостей в неизменяемом состоянии, вы сможете получить чистую и безопасную среду.
В средах Linux и macOS вредоносные бинарные файлы считывают хранилища паролей браузеров и выгребают подчистую ключи AI API, AWS Access Key и SSH-ключи, прописанные в переменных окружения. Вам нужно прямо сейчас проверить, не были ли раскрыты учетные данные в среде терминала.
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
Если будут найдены ключи, обнаженные в виде открытого текста, не закрывайте на это глаза и немедленно отозовите их. Также проверьте область действия (스코프) токенов, авторизованных через GitHub CLI.
bash gh auth status
Токены Classic с доступом ко всем репозиториям удаляйте без колебаний. При повторном создании PAT указывайте только конкретные репозитории и ограничивайте область прав минимальным уровнем "только для чтения".
Чтобы изолировать локальный хост и процессы разработки, следует использовать структуру DevContainer. Создайте файл .devcontainer/devcontainer.json в корне проекта и настройте образ, как показано ниже.
json { "image": "mcr.microsoft.com/devcontainers/javascript-node:22", "postCreateCommand": "npm ci --ignore-scripts" }
Запуск контейнера в таком виде позволяет выполнять установку пакетов и сборку в полной изоляции от системных учетных данных самого ноутбука, что перекрывает каналы утечки корпоративных активов на корню.
