Кампания wfx-loot использовала похищенные учётные данные 4837 скомпрометированных аккаунтов GitHub, чтобы проверить возможность записи в 61 764 репозитория. По данным компании по безопасности приложений Aikido, вредоносный код запустился как минимум в 1835 репозиториях и передал злоумышленнику доступные ему учётные данные.
Атака началась 10 ноября около 12:45 UTC. С захваченных аккаунтов отправляли запросы docs: dependency audit notes, проверявшие право записи в репозиторий. При наличии доступа вредоносный код внедряли в GitHub Actions или запускали при установке npm-пакета.
Украденные токены могли использоваться для получения временных облачных сеансов. Если у системы сборки были достаточные права, сценарий позволял создавать долговременные ключи или менять политики доверия. Поэтому одной смены исходного пароля или токена может быть недостаточно: после подтверждённого запуска необходимо проверить созданные учётные данные, роли и правила доступа в облаке.
Читайте также
После вывода данных злоумышленник откатывал изменения и удалял запись о запуске вместе с журналами. По оценке Aikido, этот этап занимал не больше минуты, а пропуск в нумерации запусков мог остаться единственным заметным следом. На момент исследования 92% проверочных запросов всё ещё были открыты, что, по мнению компании, указывает на то, что владельцы многих репозиториев не заметили активность.
Среди скомпрометированных учётных записей BleepingComputer называет аккаунты, связанные с организациями из Fortune 100, Управлением общих служб США, французскими государственными структурами, Nextcloud и WebdriverIO. Это не означает, что вредоносный сценарий запустился во всех репозиториях этих организаций: 1835 — минимальная оценка для всей кампании.
Около 50 аккаунтов могли публиковать пакеты. Код попал как минимум в пакет Packagist и файлы GitHub Actions Go-модуля; заражение пользователей Go-модуля не подтверждено.
Владельцам репозиториев следует проверить ветку wfx-docs, запросы docs: dependency audit notes, подозрительные изменения процессов сборки и пропуски в истории запусков. Если сценарий выполнялся, нужно сменить все доступные ему секреты и ключи, а затем проверить облачные роли, созданные учётные данные, активные сеансы и изменения политик доверия в AWS, Azure и Google Cloud.