В гитхабе прямо сейчас есть тысячи репозиториев, которые распространяют вирусы. Любой из вас может найти такие репозитории и для этого вам не нужны какие‑то специальные знания. Вам достаточно воспользоваться обычным поиском на сайте гитхаба.
Такие репозитории существуют уже 2 года. У гитхаба есть миллиарды долларов, служба безопасности и искусственный интелект. Почему они за 2 года не решили эту проблему?
Сначала мы посмотрим на уже найденные репозитории, найдем в них одинаковые паттерны, а затем по этим паттернам найдем другие репозитории.
Посмотрите на эти репозитории, в каждом из них в readme находится ссылка на zip архив с трояном:

Если мы скачаем этот zip архив и отправим отдельные файлы из него в VirusTotal, то получим такую картину:

Даже при беглом просмотре этих репозиториев мы увидим, что у них одинаковая структура, почти одинаковые заголовки, и в каждом заголовке есть эмодзи. Это вся информация которая нам нужна для поиска других репозиториев.
Давайте возьмем заголовок "? Download" и сделаем поиск по этой строке в гитхабе. Но нам нужно искать не по всему коду, а только по readme файлам. Откройте сайт github.com и сверху в строке поиска введите:
path:readme.md "## ? Download"
Количество результатов будет всегда разным. У меня он сначала показал 9К репозиториев, а когда я перешел на 2 страницу, то уже было 109 репозиториев. После обновления страницы снова 9К репозиториев.
В выдаче вам нужно визуально отбросить результаты, в которых есть какой‑то другой текст, а не только заголовок. Варианты заголовков будут примерно такие:
## ? Download Now
## ? Download Now Again
## ? Download the Software
## ? Download & Install

Откройте эти репозитории. В них будет ссылка на zip архив с трояном.
Но в результатах поиска будет много легитимных репозиториев. Мы можем улучшить поиск, добавив поиск по zip архиву. Строка поиска получится такой:
path:readme.md "## ? Download" ".zip"
(Редактор хабра автоматически исправляет прямые кавычки на типографские. Нет никакой возможности отключить автоматическое исправление. Заменяйте кавычки на обычные прямые.)
Это гораздо улучшит выдачу. Теперь прямо в поиске мы видим, в каких из репозиториев есть нужный нам заголовок и ссылка на zip архив.

Но и в этих результатах есть легитимные репозитории. Как еще можно улучшить поисковый запрос?
Все ссылки на zip архивы ведут на githubusercontent.com или на github.com. Также zip архив содержит номер версии, например Software-3.6.zip. Значит нам просто нужно написать регулярное выражение для поиска таких ссылок. Но как я и говорил в начале, вам не нужны знания для этого. С этим справится любая бесплатная ИИ модель. Отправляем ей 10 таких ссылок, и через несколько итераций получаем такой результат:
path:README.md /raw\.githubusercontent\.com\/.*\d+\.\d+\.zip|github\.com\/.*\/raw\/refs\/heads\/.*\d+\.\d+\.zip/
Вводим этот запрос и получаем репозитории, которые распространяют zip архив с трояном. Количество репозиториев всегда разное. В моем случае иногда 111, иногда 4.4К.

Но ведь весь этот поиск сработал только потому, что у нас был изначальный список репозиториев, из которых мы смогли составить общий паттерн для поиска.
Может у службы безопасности гитхаба не было этих репозиториев?
Может они не знают об этом общем паттерне?
Месяц назад я опубликовал статью, в которой подробно разобрал эту схему. Я написал скрипт, который нашёл 10,000 таких репозиториев. Список всех репозиториев и этот скрипт я опубликовал на гитхаб.
Статья попала на главную страницу Hacker News. Об этой схеме написали другие сайты по кибербезопасности.
Вот полный список действий, которые предприняли в GitHub:
Они удалили все 10К репозиториев, которые нашёл скрипт.
Всё. Больше они ничего не сделали.
Более того, спустя несколько часов я снова запустил скрипт, он нашёл новые репозитории, я добавил их в статью. За целый месяц их не заблокировали. Хотя им нужно было просто еще раз открыть мою статью, взять новые ссылки и заблокировать эти репозитории. Для них это оказалось слишком сложно.
Но мы можем сделать вывод: они прекрасно знают об этой схеме распространения вирусов.
Сколько бы я не пытался, я не могу найти ответа на вопрос, почему так происходит. Microsoft это корпорация с миллиардными доходами. У них тысячи сотрудников, безграничные возможности и искусственный интеллект. Всё что им нужно было это выделить несколько дней любого штатного сотрудника, чтобы он с помощью Copilot нашёл все эти репозитории и заблокировал их.
Я никогда не работал в крупных компаниях. И я не представляю, как принимаются решения именно в гитхабе и какой бюрократический ад менеджерам нужно пройти, чтобы начать борьбу с вредоносными репозиториями.
Но ведь они за несколько часов после публикации первой статьи удалили все 10К репозиториев.
Почему они остановились и больше не предприняли никаких действий?
Все мои статьи вы можете найти на моём сайте.
Подписаться можно по почте, RSS или в телеграм канале.
Комментарии (17)

sshmakov
26.07.2026 18:03какой бюрократический ад менеджерам нужно пройти
Менеджеры минимизируют свои усилия и, особенно, личную инициативу. У них нет повода проходить бюрократический ад, пока с них этого не требуют.

ZurgInq
26.07.2026 18:03Автор предлагает автоматически удалять любой репозиторий который попал под общую регулярку аля "download now"?

orchidfiles Автор
26.07.2026 18:03В статье был пример, как с помощью регулярки и обычного поиска на сайте гитхаба любой человек может найти репозитории, которые с большой вероятностью распространяют троян. А это значит, что команда безопасности гитхаба, с их ресурсами и возможностями, тоже могла это сделать.
Автоматизировать можно не только поиск, но и проверку файлов на вирусы. И после проверок скрипт мог бы составлять список репозиториев для последующей ручной проверки человеком, который примет окончательное решение об удалении репозитория.
"download now" был первой строкой поиска, под который попадало много легитимных репозиториев, о чём в статье и было указано. Я и подумать не мог, что после прочтения у вас появится мнение, что по этой строке поиска нужно автоматически удалять любой репозиторий.

antkatcin
26.07.2026 18:03Ну как минимум проблема в следующем: добавишь поиск по regex - злоумышленники лишь подстроятся под это, нужно будет новое изменение вводить. Если так накидывать regex'ы то быстро наберется какой-то снежный ком разных проверок, которые рано или поздно ударят по нормальным репозиториям.
Я не говорю, что над этим не нужно работать, но решение проблемы чуть более комплексное, чем просто раз прогнать базу.
orchidfiles Автор
26.07.2026 18:03Если злоумышленники подстраиваются, то это проблема. Но кажется написать регулярку, которая ищет zip архивы или исполняемые файлы в readme, можно было давно. Всё зависит от желания менеджеров гитхаба и вычислительных ресурсов.
Можно предположить, что за 18 лет существования гитхаба у них не возникло такой бизнес задачи.
Но в схеме, о которой написано в этой статье, злоумышленники не подстраиваются. Они используют одинаковую схему уже 2 года и продолжают её использовать. В каждом из этих репозиториев также есть последний коммит, который называется "Update README.md". Я написал скрипт, который нашёл 10К таких репозиториев.
Паттерн поиска оказался настолько точным, что команда гитхаба удалила все эти репозитории. Вопрос в том, почему они больше ничего не сделали. Почему они не запустили скрипт, не написали свой скрипт, не провели анализ репозиториев вручную.

Kenya-West
26.07.2026 18:03Если злоумышленники подстраиваются, то это проблема
"No shit Sherlock!" ©
Кажется, вы начинаете что-то понимать в этой теме, верно?

ReadOnlySadUser
26.07.2026 18:03Так вроде в этом и смысл любой защиты? Заставить подстраиваться так долго, чтобы злоумышленник (по крайней мере большая часть из них) - сочли это неразумной тратой времени.

Ku6epXBOCTuK
26.07.2026 18:03Почему-то морозить аккаунты обычным пользователям - нормально, а подозрительные репозитории - нет? Мой аккаунт заморозили, уже больше двух недель никакого ответа нет

lummite
26.07.2026 18:03Наткнулся на статью и появился такой вопрос от новичка в этой сфере, так как я недавно начал пользоваться гитом. Есть ли какие-либо универсальные способы проверки репозитория на подозрительные файлы? Кроме скачивания исходного кода и загрузки его на VirusTotal, конечно.

MountainGoat
26.07.2026 18:03Скачай репу и повелевай LLM агенту проверить. Для этого специально сконфигурируй агента, у которого права только на чтение и только внутри репы.
Универсальнее способа нет и не будет. Раньше LLM станет достойным антивирусом, чем напишут надёжный антивирус для Linux.

Hlad
26.07.2026 18:03Есть ли какие-либо универсальные способы проверки репозитория на подозрительные файлы? Кроме скачивания исходного кода и загрузки его на VirusTotal, конечно.
Вы же сами и указали универсальный способ.

lolikandr
26.07.2026 18:03Всё что нужно - показывать дату и результат проверки архива на virustotal прямо на странице github. А там уж пусть человек принимает решение - хочет он это скачать или нет.

TraX325
26.07.2026 18:03Очень скромные и прилежные мошенники, звёзды не накручены, репозиторий внешне выглядит адекватно, ридми опрятный. Я уже привык видеть тонны одинаковых "FC26 Mod Manager" с сотнями звёзд и единственным файлом с кодом main.py или manager.py, внутри которого сиротливая строчка
print('супер тест репозитория')(да, у большинства одна и та же структура и одна и та же несчастная строка кода). Кстати, у последних больше шансов улизнуть от проверок сторонними антивирус решениями - ссылка на скачивание обычно ведёт на контент соседнего репозитория, а скан текущего ничего не даст, это ведь просто тест репозитория.
orchidfiles Автор
26.07.2026 18:03Репозитории выглядят адекватно, потому что они копируют всю историю коммитов из чужих репозиториев. При этом сохраняется даже список контрибьюторов. Также они каждые несколько часов отправляют коммит с единственным изменением в readme файле. Таким образом эти репозитории всегда показываются сверху в результатах поиска, потому что обновлялись недавно.
UniInter
Интересно, кто минус за статью поставил? Автор одного из описанных репозиториев?
MountainGoat
Я не ставил.