Чем вообще занимается служба безопасности GitHub?

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

Такие репозитории существуют уже 2 года. У гитхаба есть миллиарды долларов, служба безопасности и искусственный интеллект. Почему они за 2 года не решили эту проблему?


Сначала мы посмотрим на уже найденные репозитории, найдем в них одинаковые паттерны, а затем по этим паттернам найдем другие репозитории.

Посмотрите на эти репозитории, в каждом из них в readme находится ссылка на zip архив с трояном:

Ссылка на скачивание zip архива с трояном

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

Проверка файлов из 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:

  1. Они удалили все 10К репозиториев, которые нашёл скрипт.

Всё. Больше они ничего не сделали.

Более того, спустя несколько часов я снова запустил скрипт, он нашёл новые репозитории, я добавил их в статью. За целый месяц их не заблокировали. Хотя им нужно было просто еще раз открыть мою статью, взять новые ссылки и заблокировать эти репозитории. Для них это оказалось слишком сложно.

Но мы можем сделать вывод: они прекрасно знают об этой схеме распространения вирусов.

Сколько бы я не пытался, я не могу найти ответа на вопрос, почему так происходит. Microsoft это корпорация с миллиардными доходами. У них тысячи сотрудников, безграничные возможности и искусственный интеллект. Всё что им нужно было это выделить несколько дней любого штатного сотрудника, чтобы он с помощью Copilot нашёл все эти репозитории и заблокировал их.

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

Но ведь они за несколько часов после публикации первой статьи удалили все 10К репозиториев.

Почему они остановились и больше не предприняли никаких действий?

Проблемы с почасовой и попроектной оплатой

Представьте, вы работаете с почасовой оплатой. Как бы вы ответили на эти вопросы?

  1. Вам пришла в голову идея, которая может улучшить финансовое состояние компании. Она пришла из ниоткуда, вы даже не думали над ней, а занимались своими повседневными делами. Компания не покупает отдельные идеи, она платит только по часам. За сколько часов она должна оплатить, если вы потратили на эту идею 0 часов?
  2. Вам поставили задачу сделать какой-то функционал. Вы вспоминаете, что вы уже делали этот функционал раньше и на реализацию потратили 50 часов. Вы переносите это решение в текущий проект за 10 минут. Всё работает, задача сделана. Компания должна оплатить за 50 часов или за 10 минут?
  3. С появлением ИИ агентов стало еще интереснее. Вы умеете их эффективно использовать и делегируете им задачу, которую сами бы делали 10 часов. Агент расписывает план, вы проверяете, он выполняет его, вы ревьювите. Несколько таких итераций и задача сделана за 30 минут. Компания должна оплатить за 10 часов или за 30 минут?
  4. Вы потратили 10 часов на решение, а потом поняли, что вы вообще всё делали неправильно, и кажется что вы в самом начале могли догадаться об этом и выбрать совсем другое решение. Должна ли компания оплачивать за это время?

Здесь есть 2 решения для исполнителя:

  1. Не работать с компаниями, которые платят по часам.
  2. Искусственно рисовать в отчёте желаемое количество часов.

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

Если вы используете готовое решение и выполняете задачу за 30 минут, то распишите в отчёте, как вы потратили на решение задачи 50 часов. Таким образом на удалёнке можно совмещать 2-4 фуллтайм работы одновременно. Вы работаете 30 часов, в отчёте указываете 150 часов, получаете оплату за 150 часов.

Почему я вообще говорю про отчёты? Менеджеры компаний, которые платят по часам, хотят видеть отчет о том, куда были потрачены эти часы. Если вы просто скажете, что на задачу ушло 50 часов, без каких-либо подробностей, скорее всего к вам появятся вопросы. Но если вы правдоподобно выдумаете на что ушло время, то эфективный менеджер откроет таблицу, увидит красивую информацию с разбивкой по часам, и его это устроит.

Можно сколько угодно говорить о том, что это нечестно. Но если мы посмотрим на реальный мир, то окажется, что деньги в большинстве случаев являются способом достижения комфортной жизни. Чем больше вы зарабатываете, тем лучше вы живёте. Конечно вы можете выбрать честный путь и надеяться, что вашу честность оценят по достоинству и в будущем дадут вам какие-то бонусы за это. Готовы ли вы жертвовать своим текущим доходом ради гипотетического будущего?

Для защиты от этого компании иногда используют приложения для автоматического скриншота экрана каждые 15 минут и просят заполнять отчет после каждого отработанного часа. Таким образом отсеиваются опытные и уверенные в себе исполнители. Остаются только те, у кого явные проблемы с поиском работы и они согласны почти на любые условия. Какое качество выполнения задач компания получит, если выберет этот подход?

Есть еще способ, чтобы не записывать в 3 раза больше часов. Просто называйте цену за час в 3 раза больше. Но если вы за час хотите 300$, а другой хочет 100$, то компания, которая выбирает сотрудника по цене, выберет другого, а не вас. Даже если платить она ему будет столько же, потому что он будет указывать в 3 раза больше часов, чем было в реальности. Тогда ваша честность и большая ставка за час оставят вас без работы.

С идеями конечно так не получится. Есть мнение, что идеи ничего не стоят, а ценность имеет только реализация. Поэтому если вам пришла гениальная идея решения какой-то проблемы, то компания не будет за это платить. Руководители считают, что эта идея уже включена в ваше оплаченное время. Если ваш час стоит 60$, а на идею вы потратили минуту, то так уж и быть, вам заплатят за идею 1$. И вы не можете в отчёте расписать, как вы придумывали эту идею десятки часов. Вы ведь не проводили никакое исследование. Это часто является причиной, почему сотрудники вообще не рассказывают о каких-то идеях руководству, которые могли бы помочь развитию компании.

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

  1. Заказчику нужно детально расписывать задачи перед началом выполнения. Что если после начала выполнения заказчик захочет поменять требования или добавить что-то? Нужно заново обсуждать условия с исполнителем.
  2. Исполнителю нужно каким-то образом правильно оценить сроки и цену. При этом он еще не знает, какие сложности возникнут в процессе выполнения. Если он ошибётся в рассчетах и выполнение займёт в 3 раза больше времени, что ему делать? Попытаться обсудить новые условия или выполнить работу на текущих условиях?
  3. Иногда на оценку проекта может уйти много часов. Заказчик может не согласиться с этими условиями, и тогда выходит, что исполнитель зря потратил своё время на оценку.
  4. Разные исполнители могут дать оцень разные оценки за один и тот же проект. Это зависит от опыта исполнителя, качества его работы, загруженности, и десятка других параметров. Как заказчику выбрать наилучшего исполнителя для проекта?

За редкими исключениями, я никогда не работаю с оплатой за каждую задачу или за проект. Ни в роли исполнителя, ни в роли заказчика. Но и с оплатой по часам я тоже не работаю.

Я выбрал для себя подход с оплатой за неделю или за месяц с очень короткими отчётами или вообще без них. Это очень хорошо работает для стартапов с маленькими командами.

Когда я ищу сотрудника, я обсуждаю с ним желаему оплату за неделю. Каждые несколько недель я смотрю на то, какую пользу принёс этот сотрудник. Я смотрю не только на выполненные задачи, но и на идеи, которые он предложил, или на его помощь другим сотрудникам, или на любую другую ценность. Мне вообще не важно сколько часов он работал. И мне не важен его отчет, потому что я всегда знаю чем были заняты сотрудники.

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

Представьте еще такую ситуацию. Компания договорилась с исполнителем на оплату за каждую неделю без учёта часов. Сотрудник работал несколько месяцев, хорошо справлялся с задачами, руководство им очень довольно. Но предыдущую неделю сотрудник не работал. Должна ли компания оплатить ему за эту неделю?

Коучи

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

В описании профиля указано, что ты научишь меня торговать криптой. Я подписался, чтобы узнать что-то новое, но пролистал месяц твоих постов и увидел только 1 совет от ИИ. Чем именно мне поможет просмотр всех твоих фотографий? Как это убедит меня что-то у тебя купить? Почему у меня должно появиться к тебе доверие?

Фотографии успеха никак не объясняют, откуда этот успех появился. Люди могли зарегистрироваться по твоим реферальным ссылкам, слить деньги после твоих советов, а ты бы заработал комиссию от их потерь.

Ок, ты завлек внимание людей, которые хотят такую же успешную жизнь. Но как ты добьешься внимания миллионеров? Они живут гораздо успешнее тебя. Ты их не завлечёшь красивой жизнью.

Сколько вам лет?

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

Поэтому я выбрал для себя другой вариант ответа. Я выбираю одно число и называю его следующие 5 лет. Или до тех пор, пока я психологически согласен с этим числом. Например, если мне от 22 до 28 лет, то я называю 25.

Людям скорее всего не важна ваша реальная дата рождения. Если вы хотите чувствовать себя моложе, называйте 30, даже если вам 35. Хотите казаться взрослее? Называйте 25, даже если вам 20.

С возрастом вы будете слышать этот вопрос гораздо реже, чем в молодости. Когда вам 17 лет, а другому человеку 20, вы думаете, что он умнее и опытнее вас. Разница в несколько лет кажется существенной. Но когда вам 40 лет, и вы общаетесь с кем-то примерно того же возраста, вам становится неважно, 35 ему лет или 45.

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

Я обнаружил крупномасштабное распространение вирусов в GitHub

Это история о том, как я нашел 10.000 репозиториев в GitHub, в которых находится ссылка на скачивание zip архива. В этом архиве — троян. Все эти репозитории от разных контрибьюторов, с разным названием и не являются форками других репозиториев. Но у всех них есть одинаковый паттерн, который и позволил написать скрипт для поиска таких репозиториев.

Начало

У меня есть проект в гитхабе и я хотел проверить, проиндексировали ли его поисковые системы. Ввёл название проекта в Google, в выдаче появился мой репозиторий. Ввёл такой же запрос в Bing, в выдаче появился чужой репозиторий. С таким же названием и описанием. Там была копия моего репозитория со всеми коммитами, а я был указан в списке контрибьюторов. Но час назад был отправлен еще один коммит с изменением readme. В нём добавилась ссылка на zip архив.

Я выбирал подходящие теги для другого моего проекта в гитхабе. Перешел по этим тегам, чтобы посмотреть аналогичные продукты. В списке нашел репозиторий, название и описание которого полностью совпадают с еще одним репозиторием из этого списка. Оказалось, что в нем также скопированы все коммиты этого репозитория, а 2 часа назад в readme была добавлена ссылка на zip архив.

Понаблюдав за этими двумя репозиториями, я выяснил, что они каждые несколько часов удаляют предыдущий коммит и снова отправляют такой же коммит. В этом коммите только 1 изменение: добавление ссылки на архив в readme файл.

Я отправил запрос в поддержку гитхаба с просьбой удалить эти репозитории. За 2 недели ничего не изменилось, поддержка гитхаба не ответила. Я обсудил с ИИ, что еще можно с этим сделать, но полезных советов он не дал. Я открыл обсуждение на гитхабе, ответили 3 человека, с таким же ИИ слопом без какой-либо пользы.

Еще через месяц поддержка гитхаба прислала мне письмо о том, что они удалили эти репозитории.

Вы можете открыть другие подобные репозитории, посмотреть последний коммит и увидеть, что несколько часов назад в readme была добавлена ссылка на zip архив:
https://github.com/lucasheriq4374/welink
https://github.com/lucioloprey/OcyShield-Framework
https://github.com/luigi1973/AssetRipper-CLI

Zip архив содержит 4 файла:

  • Application.cmd или Launcher.cmd
  • loader.exe или luajit.exe или another_name.exe
  • random_name.cso или random_name.txt
  • lua51.dll

Если указать ссылку на архив в VirusTotal, он найдет 0 вирусов.
Если отправить zip файлом, он найдет в нём троян.

Продолжение

Казалось, я уже забыл об этом событии, но моё подсознание не забыло. И часто подсознание подкидывает мне интересные идеи когда я сплю или просыпаюсь. Недавно я проснулся и в ту же секунду понял, что мне нужно сделать. Мне нужно составить общий паттерн, а затем написать скрипт, который проанализирует все репозитории гитхаба и найдет среди них те, которые попадают под этот паттерн.

Паттерн для поиска:

  • Каждые несколько часов удаляется предыдущий коммит и отправляется новый
  • В коммите обновляется только readme файл
  • В readme файле находится ссылка на zip архив
  • Коммиты скопированы с другого репозитория
  • Это новый репозиторий, а не форк
  • У всех репозиториев разные контрибьюторы и разные названия

Из последних 2 пунктов становится понятно, что даже если мы найдем один такой репозиторий, мы не сможем по нему найти другие подобные репозитории. Но в гитхабе 500 миллионов репозиториев. Как нам их все проанализировать? Гитхаб позволяет делать 5.000 запросов в час с одним токеном. Для каждого репозитория нам надо сделать несколько запросов для получения списка коммитов, измененных файлов и контента readme файла. Я не хотел ждать год, пока скрипт проанализирует все репозитории.

Но ведь нам не нужны все репозитории, нам нужны только те, которые обновляются каждые несколько часов. Я нашел сервис gharchive, с которого можно скачать все события гитхаба за любой день. Значит нам нужно получить события за последние дни, найти из них пуш коммитов, и найти репозитории, которые обновляются от 2 до 10 раз каждые 10 часов.

За последние 5 дней было 16 миллионов пушей коммитов. Из них всего 3.000 репозиториев, которые обновляются каждые несколько часов.

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

После запуска сприпт выдал много репозиториев. Я добавил в фильтры несколько параметров:

  • Коммит должен быть от пользователя, а не от бота
  • Между последним коммитом и предпоследним прошло более месяца
  • В репозиториях больше одного контрибьютора

После этого нашлось только 14 репозиториев, которые полностью совпадают с паттерном. И мне не давал покоя вопрос, почему нашлось так мало репозиториев? Какая вероятность того, что я наткнулся на эти репозитории 2 месяца назад и их всего 14 штук по всему гитхабу? Ведь их должно быть гораздо больше. Представьте, какой был бы заголовок этой статьи, если бы я нашел миллион таких репозиториев, ну или хотя бы тысячу.

Но я смирился с тем, что их всего 14, и начал писать эту статью. Я решил перепроверить их еще раз, чтобы не добавить в статью лишние репозитории по ошибке. И какого же было мое удивление, когда я увидел, что все они обновлялись последний раз 20 часов назад. Значит параметр "обновляются каждые несколько часов" был вообще не правильный. Фильтр отбросил все репозитории, которые обновляются редко.

Еще при ручной проверке я увидел репозитории, в которых есть ссылка на zip архив и есть недавний коммит, но в нём 0 изменений. А фильтр учитывал только репозитории, в которых был изменен 1 файл readme в последнем коммите.

Еще я заметил, что последний коммит во всех этих репозиториях называется одинаково: "Update README.md".

Я поменял фильтр. Теперь скрипт искал репозитории, которые обновлялись от 1 до 24 раз каждые 24 часа. Таких репозиториев нашлось 40.000.

Репозиториев, которые полностью совпадают по паттерну — 10.000. Это 25% от общего количества.

Каждый из этих репозиториев содержит zip архив с трояном.

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

Полный список репозиториев я опубликовал на GitHub
Скрипт для поиска таких репозиториев: Git Malware Finder

Открытые вопросы

  1. Почему они копируют только новые репозитории, а не популярные?
  2. Зачем они удаляют коммит и отправляют новый каждые несколько часов?
  3. Почему гитхаб не детектит такие репозитории автоматически?
  4. Что именно делает исполняемый exe файл из архива?
  5. Какой реальный масштаб этой кампании?

Мои предположения

Задача хакеров — понять, как работает система, найти в ней ограничения и уязвимости, и воспользоваться этой информацией. Если перезаписывание коммитов помогает обойти алгоритмы безопасности гитхаба, то они этим воспользовались. Возможно, по этой же причине каждый коммит называется "Update README.md".

Вторая задача это распространение вируса. Как сделать так, чтобы люди его нашли и скачали? Думаю для этого они копируют только новые репозитории и сразу попадают в топ выдачи поисковых систем по низкочастотным запросам. И они добавляют эти репозитории в популярные теги гитхаба, чтобы увеличить шанс индексации, и чтобы люди нашли эти репозитории из этих тегов.

Но почему они копируют все коммиты и контрибьюторов? Ведь они могли просто скопировать весь исходный код? Это возможно сделано для доверия. Когда человек заходит в репозиторий, он видит контрибьюторов, может в них перейти и увидеть, что это не аккаунты однодневки. И сохраняется история коммитов, чтобы было понятно, что репозиторий появился не вчера. Но возможно это также сделано для обхода алгоритмов гитхаба.

Это только мои предположения, а реальность может быть совершенно другая.

Заключение

У меня было ограничение API гитхаба на 5.000 запросов в час. Я оптимизировал скрипт для поиска только подходящих репозиториев, и думаю из-за фильтра скрипт нашел только малый процент репозиториев. У команды гитхаба таких ограничений нет. Они могут проанализировать все 500 миллионов репозиториев, найти в них любые архивы или исполняемые файлы и проверить их на вирусы.

На этот раз я не буду отправлять запрос в GitHub. Репозиториев слишком много. Если у кого-то из вас есть прямой контакт со службой безопасности гитхаба, отправьте им ссылку на эту статью.

* Обновление
Нашел такую статью от 18 апреля: How 109 Fake GitHub Repositories Delivered SmartLoader and StealC
В ней подробно рассказывается, как работает этот троян. На тот момент автор статьи нашел 109 таких репозиториев.

* Обновление 2
Гитхаб начал удалять все репозитории, которые нашёл скрипт. Большинство из этих репозиториев уже не доступны.

* Обновление 3
Нашёл пост на Reddit с упоминанием этой схемы. Он был размещен в феврале 2025, почти 1.5 года назад: If you’re creating new repositories, they are being spoofed to host malware

* Обновление 4
Гитхаб удалил только те репозитории, которые я опубликовал в полном списке в txt файле. Затем я запустил скрипт еще раз, он нашёл новые репозитории, я добавил их в эту статью. Прошло 14 дней, эти репозитории не были удалены. У гитхаба нет способа поиска этих репозиториев. Они не запустили мой скрипт, они не написали свой скрипт. Они даже не открыли эту статью, чтобы посмотреть, изменился ли в ней список репозиториев. Они удаляют только репозитории, о которых им сообщают, но больше они ничего не делают. Поэтому эта схема существует уже несколько лет, и скорее всего продолжит существовать.

* Обновление 5
Мне скинули такую статью: The rise of malicious repositories on GitHub. В ней автор нашёл такую же схему распространения zip архива. Просто введите в поиске гитхаба "path:README.md /software-v.*.zip/" и вы получите список таких репозиториев. Что примечательно, некоторые из них не обновлялись полгода, а некоторые являются форками других репозиториев. Но что более важно, я в результатах поиска увидел репозитории, в которых 30 минут назад был обновлён readme. Вы представляете? Команде гитхаба даже не нужен скрипт. Они могут обычным поиском найти такие репозитории.

* Обновление 6
Еще одна статья: FakeGit: LuaJIT malware distributed via GitHub at scale. В ней подробно рассказывается об этапах развития этой схемы, от первого деплоя смарт-контракта в марте 2025 до наших дней. Также в ней детальный разбор всей инфраструктуры, IP адреса по которым стучится троян и хеши архивов с ссылками на VirusTotal.