Как заброшенные аккаунты на GitHub превратились в оружие для слежки за компаниями

Специалисты Datadog Security Labs наткнулись на нечто необычное: десятки старых, годами неактивных аккаунтов GitHub вдруг начали синхронно опрашивать API платформы, методично составляя карту корпоративных организаций, репозиториев и пользователей. Причём делали это не хаотично, а по чёткой схеме, растянутой на несколько недель.
Как заброшенные аккаунты на GitHub превратились в оружие для слежки за компаниями
Изображение носит иллюстративный характер

Речь идёт о более чем 50 «спящих» аккаунтах, созданных от двух до пяти лет назад. Всё это время они просто существовали — без единого коммита, без активности, ничем не привлекая внимания. А затем их будто разбудили и пустили в дело. По словам старшего инженера по безопасности Datadog Джули Агнес Спаркс, именно в этом и заключается расчёт атакующих: аккаунт с историей в несколько лет не вызывает подозрений так, как свежесозданный профиль, зарегистрированный вчера ради разовой операции.
Параллельно с «призрачными» аккаунтами злоумышленники задействовали и другой канал — украденные OAuth-токены и персональные токены доступа (PAT), принадлежащие вполне реальным пользователям. Таких скомпрометированных учёток набралось несколько десятков, и они добавляли операции ещё один слой правдоподобности: запросы шли как бы от имени легитимных разработчиков.
Инструментарий для сканирования тоже впечатляет своей проработкой. Это не примитивный скрипт для одноразового парсинга, а версионируемая система, которая менялась и дорабатывалась прямо в процессе кампании. Запросы маскировались под легитимные или похожие на легитимные user-agent'ы, что дополнительно усложняло фильтрацию по сигнатурам.
Основная цель — публичные данные: списки организаций, репозиториев, участников команд. Казалось бы, ничего секретного, GitHub и так открывает значительную часть своего API без авторизации. Но в нескольких случаях наблюдатели зафиксировали переход границы: атакующие не просто перечисляли публичные репозитории, а клонировали приватные. Как минимум для одной организации подтверждён факт доступа к закрытому коду.
Здесь и кроется главная сложность обнаружения подобной активности. Отдельно взятый запрос выглядит абсолютно рутинно — обращение к публичному эндпоинту, чистая или вовсе отсутствующая аутентификация, успешный ответ сервера. Ничего похожего на классические индикаторы компрометации. Проблема проявляется только при сопоставлении множества запросов между собой, когда становится видно: группа аккаунтов двигается синхронно, обходит одни и те же организации в одинаковом порядке, использует одну и ту же кастомную тулзу разных версий.
В Datadog это описали предельно конкретно: «По отдельности большинство этих запросов ничем не примечательны. Они обращаются к публичным эндпоинтам, проходят аутентификацию чисто или вообще без неё, и возвращают успешные ответы. Проблема — в совокупности: группа аккаунтов, синхронно перемещающихся по GitHub-организациям разных компаний с версионируемым кастомным инструментарием, работающим неделями, а в худшем случае — субъекты, которые перестали просто сканировать и начали клонировать».
Схема атаки укладывается в четыре последовательных этапа. Сначала идёт автоматизированная разведка — сбор данных об организациях, репозиториях и пользователях через открытый API. Затем подключаются механизмы доступа: спящие аккаунты вперемешку с угнанными OAuth-токенами и PAT. На третьем этапе часть операторов переходит от простого перечисления к активному клонированию приватных репозиториев. И всё это держится на одном простом трюке — использовании состарившихся, ничем не примечательных учёток вместо свежих, которые сразу привлекли бы внимание систем мониторинга.
Для служб безопасности компаний, использующих GitHub, это довольно неприятный сигнал. Классические подходы к обнаружению аномалий — поиск подозрительных user-agent'ов, свежесозданных аккаунтов, всплесков активности с одного IP — здесь просто не работают. Нужна корреляция на уровне организации целиком: сопоставление паттернов запросов от разных, казалось бы, независимых пользователей, отслеживание совпадений в тайминге и последовательности обращений к репозиториям.


Новое на сайте

20327Кости прерий: как истребление бизонов породило целую индустрию — и сама себя же уничтожила 20326Кто и зачем взламывает серверы Ollama и ComfyUI ради ключей от AWS? 20325Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно... 20324Брюссель заставляет Android делиться секретами с чужими ИИ-помощниками 20323WordPress: как два бага слились в одну критическую дыру, которую назвали wp2shell 20322Как китайские хакеры обманули DigiCert и украли сертификаты для подписи кода? 20321Что скрывается за уязвимостью, которую агентство США внесло в список активно используемых... 20320Автономные системы наступают быстрее, чем инфраструктура для управления ими: кто выиграет... 20319Почему в OpenSSL нашли дыру, съедающую память серверов, но не дали ей даже номер CVE? 20317SonicWall SMA 1000: как два бага превратили VPN-шлюз в бэкдор для атакующих 20316Может ли уязвимость в клиенте Zoom для Windows открыть доступ к чужому аккаунту без... 20315TELEPUZ: новый вредонос на C, который научился прятаться в Telegram, Steam и блокчейне... 20314Дома из дёрна: как исландцы триста лет прятались от холода под слоем земли и травы 20313Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?
Ссылка