Фейковые репозитории GitHub: как проверить проект до скачивания

Готовые программы, библиотеки и инструменты для разработки часто ищут на GitHub — напрямую или через Google. Злоумышленники пользуются привычкой доверять знакомому домену: копируют названия продуктов, оформляют страницы как официальные и помещают в README ссылку на вредоносную загрузку.

В 2026 году исследователи описали несколько таких сетей. Arctic Wolf Labs обнаружила 292 поддельных ресурса, Socket связала между собой 222 репозитория, а Island изучила операцию FakeGit примерно с 7600 вредоносных проектов. Это разные расследования: их показатели нельзя складывать в общую статистику заражений.

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

Сравнение исследований

Показатели относятся к разным исследованиям: их нельзя суммировать.

292 поддельных GitHub-ресурса: июльская находка

13 июля 2026 года Arctic Wolf Labs опубликовала технический разбор кампании, наблюдавшейся как минимум с 26 июня. Исследователи нашли 292 поддельных ресурса — страницы организаций и репозитории `.github`, имитировавшие поставщиков программного обеспечения, в том числе Arctic Wolf. Среди приманок были инструменты ИБ, кошельки, программы для разработчиков и игровые утилиты.

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

Из README пользователь попадал на страницу `github.io`, затем — на домен распространения и поддельную страницу безопасной загрузки. Она выдавала ZIP-архив. На момент анализа работали 78 перенаправляющих страниц; исследователи также нашли около 20 доменов инфраструктуры.

Архив постоянно менялся: его имя и поставляемый образец пересоздавались примерно раз в 60 секунд. Внутри находился легитимный подписанный файл программы обновления WinGUP gup.exe, переименованный под продукт, который имитировался, и вредоносная библиотека libcurl.dll.

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

Вредонос собирал данные браузеров, Telegram, Discord, Steam, диспетчера учетных данных Windows, пользовательских файлов и криптокошельков; поддерживался захват экрана. В коде упоминалось более 19 браузеров. Таблица целей для криптокошельков содержала 41 путь файловой системы, относящийся примерно к 32 брендам.

Для браузеров семейства Chromium исследователи также разобрали обход механизма App-Bound Encryption — защиты, которая привязывает расшифровку чувствительных данных к доверенному контексту браузера. Вредонос внедрял библиотеку непосредственно в процесс браузера, получал ключ через доверенный контекст и передавал его обратно через общую область памяти.

Двоичное сравнение показало общую кодовую базу с BoryptGrab. Arctic Wolf Labs не установила оператора июньской кампании: общность кода, русскоязычные следы и расположение серверов не позволяют уверенно назвать конкретного человека или группировку.

Кто расследует поддельные репозитории

Расследование началось с того, что команда безопасности Arctic Wolf заметила поддельную страницу собственного бренда. Исследователи сопоставили аккаунты, ссылки из README, домены, перенаправления и скачиваемые образцы.

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

Разведка по открытым источникам — OSINT — здесь оказывается одним из инструментов. Значительная часть первоначальной инфраструктуры публична: GitHub-профили, история изменений, домены, страницы сайтов, поисковая выдача, сертификаты, сведения о размещении серверов и архивные версии ресурсов.

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

В рекомендациях NIST SP 800-61 Rev. 3, опубликованных в апреле 2025 года, реагирование на инциденты встроено в управление киберриском. Для расследования нужны и внешние сведения, и внутренние журналы событий, данные конечных устройств и сети.

Фейковые инструменты для ИИ стали следующей приманкой

20 июля 2026 года Island описала FakeGit: около 7600 вредоносных репозиториев, созданных примерно 6600 профилями. Около 1400 проектов касались ИИ-инструментов, агентов или рабочих процессов. Более 800 имитировали Skills либо серверы MCP — протокола, через который ИИ-приложения подключаются к инструментам и данным. Эти приманки более 600 раз встречались в публичных каталогах ИИ-инструментов.

Для примерно 200 репозиториев FakeGit исследователи насчитали более 14 млн скачиваний файлов GitHub Releases. Это число загрузок, а не подтвержденных заражений. Во время тестов автоматические агенты находили вредоносные проекты при поиске инструментов для обычных задач.

Описание, README и инструкции помогают вредоносному проекту попасть в поисковую выдачу, каталог инструментов или результаты поиска автоматического агента. Так злоумышленники достигают и пользователей, и ИИ-агентов.

BoryptGrab распространяли еще до июльской волны

5 марта 2026 года Trend Micro описала BoryptGrab — семейство программ для кражи информации, распространявшееся через поддельные GitHub-репозитории с конца 2025 года.

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

Один из примеров имитировал Voicemod Pro. Во время наблюдения фальшивая страница GitHub находилась в поисковой выдаче сразу под настоящим результатом. Пользователь видел знакомый бренд и домен github.com, а затем переходил по ссылке на стороннюю загрузку.

Исследователи обнаружили более ста связанных ресурсов. Самые ранние найденные ZIP-файлы относились к концу 2025 года, а следы активности некоторых связанных аккаунтов — ещё раньше. Помимо BoryptGrab, отдельные варианты цепочки могли доставлять другие компоненты, включая вариант Vidar, загрузчик и программу для создания обратного SSH-туннеля — соединения, позволяющего оператору получить дополнительный сетевой доступ к заражённой системе.

В этой схеме GitHub служил витриной, а реальная доставка вредоносного файла происходила после перехода по ссылке.

Подписанный EXE-файл тоже может быть частью атаки

В июльской кампании Arctic Wolf подписанный исполняемый файл WinGUP запускался рядом с вредоносной `libcurl.dll`. При обращении к библиотеке легитимная программа сама загружала код атакующего.

Так работает DLL side-loading: приложение загружает подставную динамическую библиотеку из подходящего каталога. Доверенный исполняемый файл при этом может оставаться неизмененным.

MITRE ATT&CK относит DLL side-loading к технике T1574.001 (Hijack Execution Flow: DLL). Для проверки архива поэтому мало посмотреть подпись EXE-файла: важны соседние библиотеки и фактическая цепочка запуска.

Почему количество звезд GitHub — не гарантия безопасности

Звезды, подписчики и форки создают впечатление популярности. Эти показатели можно накручивать с помощью сетей аккаунтов, которые имитируют интерес к проекту.

Авторы системы StarScout изучили события GitHub за период с июля 2019-го по декабрь 2024 года и нашли около 6 млн предположительно искусственных звезд. После дополнительной фильтрации они выделили 18 617 репозиториев с признаками кампаний накрутки и примерно 301 тыс. участвовавших аккаунтов. Это результат алгоритмического анализа, а не независимое подтверждение каждого случая.

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

Для проверки методики исследователи использовали известную вредоносную инфраструктуру Stargazers Ghost Network. StarScout обнаружил 688 из 847 репозиториев контрольного набора и почти 12 тыс. из примерно 15,7 тыс. связанных подозрительных аккаунтов.

При оценке популярности полезнее смотреть на историю появления звезд и реальные обсуждения проекта. Внезапный рост активности от однотипных аккаунтов — повод проверить репозиторий внимательнее.

Stargazers Ghost Network: как создают ложную репутацию

В июле 2024 года Check Point Research описала Stargazers Ghost Network. В сети одни аккаунты создавали приманки, другие публиковали вредоносные релизы, третьи ставили звезды и делали форки. Так массовые действия связанных профилей выдавали за органический интерес к проектам.

За относительно короткий период наблюдения исследователи обнаружили более 2 200 вредоносных репозиториев, связанных с такой деятельностью. Одна из отслеженных кампаний распространяла программу Atlantida Stealer, предназначенную для кражи учетных данных, данных криптовалютных кошельков и другой персональной информации. По оценке исследователей, менее чем за четыре дня она привела более чем к 1 300 заражениям.

Разделение функций между аккаунтами помогало сети продолжать работу после блокировки отдельных репозиториев или профилей.

Коммиты тоже можно накрутить

Длинная история изменений производит впечатление живого проекта. Но автоматический коммит в один служебный файл может повторяться месяцами без развития исходного кода.

8 июля 2026 года Socket сообщила об операции Muck and Load. Расследование вредоносного Go-модуля под видом DNS-сканера привело к сети из 222 подтвержденных репозиториев в 190 аккаунтах GitHub.

Оператор использовал GitHub Actions для автоматических изменений служебных файлов. Сценарий мог запускаться каждую минуту и создавать новые коммиты, из-за которых история казалась насыщенной, а число Go-псевдоверсий росло.

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

Связать разные аккаунты помогли повторявшийся адрес автора коммитов, одинаковый сценарий GitHub Actions и сходные приемы доставки вредоносного ПО.

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

Старые аккаунты также используют в атаках

Возраст профиля — слабый критерий доверия. Существующий несколько лет аккаунт могут задействовать после долгой паузы или скомпрометировать.

8 июля 2026 года Datadog Security Labs описала кампании автоматизированного сбора сведений о корпоративных организациях GitHub. С октября 2025 года исследователи подтвердили более 50 «спящих» аккаунтов, созданных за два–пять лет до наблюдаемой активности. Эта история касалась прежде всего разведки через API, а не распространения тех же вредоносных архивов.

В других эпизодах злоумышленники применяли похищенные OAuth-токены и персональные токены доступа настоящих пользователей. Datadog также описала случаи, когда обращения выходили за пределы публичных данных и в отдельных случаях приводили к успешному клонированию закрытых репозиториев.

Важнее последовательность действий владельца: прежние проекты, обсуждения, содержательные изменения кода и резкие перемены в поведении аккаунта.

Как проверить GitHub-репозиторий до скачивания программы

Начните с официального сайта разработчика: найдите ссылку на его GitHub-организацию или репозиторий и переходите по ней. Результат поисковой выдачи легко подменить страницей с похожим названием.

Сравните имя организации и адрес репозитория посимвольно. Дополнительное слово `official`, дефис или похожая буква требуют проверки по независимому каналу. Затем откройте историю коммитов и посмотрите, что именно меняли авторы: исходный код, зависимости и тесты или один журнал с автоматически обновляемой датой.

Проверьте конечный адрес кнопок `Download`, `Official Page` и `Secure Download` в README. Переход на `github.io` или сторонний сайт сам по себе допустим, но требует проверки связи этого домена с официальным разработчиком.

Сравните способ распространения с документацией самого продукта. Неизвестный ZIP с исполняемым файлом вместо привычного официального установщика — повод остановить загрузку и проверить источник.

Что означает отметка Verified у изменения на GitHub

GitHub позволяет разработчикам подписывать коммиты и метки версий с помощью криптографических механизмов GPG, SSH или S/MIME. При успешной проверке подписи GitHub может показать состояние Verified.

Отметка `Verified` у коммита означает, что GitHub проверил его криптографическую подпись. Она не оценивает безопасность исходного кода и не распространяется на соседние файлы в ZIP-архиве. Кроме того, GitHub сохраняет запись о проверке: прежний статус Verified может остаться видимым после отзыва или истечения срока действия ключа.

Как проверить готовый файл до запуска

SHA-256 помогает убедиться, что скачанный файл совпадает с эталоном, опубликованным разработчиком. Сравнивать контрольную сумму нужно с независимым официальным источником: злоумышленник способен разместить вредоносный архив и правильный хеш для него на одной поддельной странице.

Подпись EXE-файла позволяет проверить подписанта этого файла. Она ничего не сообщает о соседних DLL, скриптах установки или компонентах, загружаемых после запуска.

Ещё один механизм — аттестация происхождения сборки. GitHub позволяет создавать криптографически подписанные сведения о том, из какого репозитория и изменения был получен артефакт, какой рабочий процесс его собрал и какое событие запустило сборку. К аттестации может добавляться перечень компонентов программного обеспечения.

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

Как из одного фейкового репозитория раскрывают целую сеть

При расследовании одного поддельного репозитория полезно сохранить название владельца, README, историю коммитов, адреса авторов, ссылки на загрузку и перечень аккаунтов, ставивших звезды. Затем можно искать повторения этих признаков в других проектах.

Одинаковый домен в README обнаруживает новые приманки. Повторяющийся адрес автора и сценарий GitHub Actions связывают аккаунты с общей автоматизацией. Похожие периоды постановки звезд помогают найти координированную активность, после чего каждую связь проверяют отдельно.

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

Где проходит граница между совпадением и доказательством

В OSINT важно понимать доказательную силу каждого совпадения. Повторяющийся ник, IP-адрес или адрес электронной почты помогает найти связанные объекты, но не всегда позволяет установить личность оператора.

Одинаковый email автора может оказаться общим служебным адресом; расположение сервера показывает размещение инфраструктуры; русскоязычный комментарий относится к конкретному фрагменту кода. Для атрибуции нужны независимые подтверждения, а не один такой признак.

Одну кодовую базу вредоносной программы могут использовать разные операторы. Поэтому Arctic Wolf Labs связала исследованный образец с BoryptGrab на уровне кода, но не перенесла на июньскую кампанию прежнюю атрибуцию.

В отчете стоит отдельно фиксировать подтвержденные факты, вероятные связи и гипотезы. Читатель должен видеть, на каком источнике основан каждый вывод.

Практический OSINT: от поиска данных до проверки источника

Поддельные репозитории приходится проверять по нескольким открытым источникам: GitHub, истории доменов, регистрационным сведениям, архивам страниц и сопоставлению цифровых идентификаторов.

OSINT-аналитик фиксирует найденные признаки, ищет повторения в независимых источниках и строит карту связей. Внутренние корпоративные инциденты дополнительно требуют журналов событий и данных конечных устройств.

Такие задачи входят в программу курса «Специалист по OSINT» (Кибердетектив) Академии КиберЕж: многоуровневый поиск, проверка достоверности источников, сопоставление email, имен пользователей и IP-адресов, работа с GitHub и Maltego. Курс рассчитан на практику расследований и оформление аналитических результатов.

На странице программы указаны девять месяцев обучения и ориентировочная нагрузка 10 часов в неделю. В учебном плане есть правовые основы OSINT, методы сбора и хранения данных, анализ соцсетей, корпоративная разведка и критическая оценка доказательств. Для специалистов, которым ближе расследование корпоративных инцидентов, у Академии есть программа «Специалист по информационной безопасности» с курсами по SOC-аналитике и безопасности Git.