Gurus

I follow a crypto blogger, but I see that almost all of his posts are about how successful he is. He flies business class, buys his wife gifts, and dines at expensive restaurants. But if I wanted to look at your photos, I’d follow you on Instagram, wouldn’t I?

Your profile bio says you’ll teach me how to trade crypto. I followed you to learn something new, but after scrolling through a month’s worth of your posts, I only saw one piece of advice from an AI. How exactly is looking at all your photos going to help me? How will that convince me to buy something from you? Why should I trust you?

Photos of your success don’t explain where that success came from. People could have signed up through your referral links, lost money following your advice, and you would have earned a commission on their losses.

Right, you’ve caught the attention of people who want the same kind of successful life. But how will you get the attention of millionaires? They live much more successful lives than you do. You won’t attract them with a picture-perfect life.

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

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

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

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

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

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

How old are you?

At first, you get used to a single number, confidently give your answer, and then realize you’ve already gotten it wrong by a year. The years fly by so quickly that it’s sometimes hard to remember. You have to calculate the difference between the current year and the year you were born.

That’s why I’ve chosen a different way to answer. I pick a single number and stick with it for the next five years. Or until I’m mentally okay with that number. For example, if I’m between 22 and 28, I say 25.

People probably don’t care about your actual date of birth. If you want to feel younger, say 30, even if you’re 35. Want to seem more mature? Say 25, even if you’re 20.

As you get older, you’ll hear this question much less often than when you were younger. When you’re 17 and someone else is 20, you think they’re smarter and more experienced than you. A difference of a few years seems significant. But when you’re 40 and interacting with someone around the same age, it doesn’t matter to you whether they’re 35 or 45.

And when you have kids, people will often ask you how old your child is. And that’s when you’ll get even more mixed up with the answer.

Я обнаружил крупномасштабное распространение вирусов в 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.

I discovered a large-scale malware distribution campaign on GitHub

This is the story of how I found 10,000 repositories on GitHub that distribute Trojan malware. They are all from different contributors, have different names, and are not forks of other repositories. But they share a common pattern, which is what allowed me to write a script to find such repositories.

Introduction

I have a project on GitHub, and I wanted to check whether search engines had indexed it. I typed the project name into Google, and my repository appeared in the results. I entered the same query into Bing, and someone else’s repository appeared in the results, with the exact same name and description. It was a copy of my repository with all the commits, and I was listed as a contributor. But an hour ago, another commit was pushed with a change to the readme. A link to a zip archive has been added to it.

I was choosing appropriate tags for another one of my projects on GitHub. I clicked through those tags to look at similar projects. In the list, I found a repository whose name and description matched exactly those of another repository on that list. It turned out that it also contained copies of all the commits from that repository, and two hours ago, a link to a zip archive has been added to the readme.

After monitoring these two repositories, I discovered that every few hours they delete the previous commit and push the exact same commit again. This commit contains only one change: adding a link to the archive in the readme file.

I submitted a request to GitHub support asking them to delete these repositories. Two weeks passed and nothing has changed; GitHub support hasn’t responded. I discussed with an AI what else could be done about this, but it didn’t offer any useful advice. I opened a thread on GitHub, and three people replied with the same AI slop that was of no use at all.

Another month later, GitHub support sent me an email saying that they had removed these repositories.

You can open other similar repositories, look at the latest commit, and see that a link to a zip archive was added to the readme a few hours ago:
https://github.com/lucioloprey/OcyShield-Framework
https://github.com/luigi1973/AssetRipper-CLI

The zip archive contains 4 files:

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

If you submit a link to the archive to VirusTotal, it will find 0 viruses.
If you submit the zip file itself, it will detect a Trojan inside it.

Continued

It seemed like I had already forgotten about this event, but my subconscious hadn’t. And my subconscious often throws interesting ideas at me when I’m sleeping or waking up. Recently, I woke up and in the very same second realized what I needed to do. I need to come up with a general pattern and then write a script that will analyze all GitHub repositories and find the ones that match that pattern.

Search pattern:

  • Every few hours the previous commit is deleted and a new one is pushed
  • Only the readme file is updated in the commit
  • The readme file contains a link to a zip archive
  • The commits are copied from another repository
  • This is a new repository, not a fork
  • All repositories have different contributors and different names

From the last two points, it becomes clear that even if we find one such repository, we won’t be able to find other similar repositories using it. But there are 500 million repositories on GitHub. How can we analyze all of them? GitHub allows 5,000 requests per hour with a single token. For each repository, we need to make several requests to get the list of commits, modified files, and the content of the readme file. I didn’t want to wait a year for the script to analyze all the repositories.

But we don’t need all the repositories, we only need the ones that are updated every few hours. I found a service called gharchive, which lets you download all GitHub events for any given day. So we need to download the event archives for the last few days, filter them to include only commit push events, and identify the repositories that are updated between 2 and 10 times every 10 hours.

Over the past 5 days, there have been 16 million commit pushes. Of these, only 3,000 are repositories that are updated every few hours.

However, the events do not include information about which specific files were modified. This means that for each relevant repository, we need to make additional requests to the GitHub API.

After running the script, it returned a large number of repositories. I added several parameters to the filters:

  • The commit must be from a user, not a bot
  • More than a month has passed between the last commit and the one before that
  • The repositories have more than one contributor

After that, only 14 repositories were found that fully matched the pattern. And I couldn’t stop wondering: why were there so few repositories? What are the odds that I stumbled upon these repositories two months ago and there are only 14 of them on the entire GitHub? There should be many more. Imagine what the headline of this article would have been if I’d found a million such repositories or even just a thousand.

But I accepted the fact that there were only 14 of them and started writing this article. I decided to double-check them one more time so I wouldn’t accidentally include any unnecessary repositories in the article. Imagine my surprise when I saw that they had all been updated 20 hours ago. So the “updated every few hours” parameter was completely wrong. The filter had discarded all repositories that are updated infrequently.

During my manual check, I also noticed repositories that contained a link to a zip archive and had a recent commit, but that commit had zero changes. The filter, however, only considered repositories where a single readme file had been modified in the latest commit.

I also noticed that the last commit in all of these repositories had the same name: “Update README.md”.

I changed the filter. Now the script searched for repositories that were updated between 1 and 24 times every 24 hours. It found 40,000 such repositories.

There were 10,000 repositories that exactly matched the pattern. That’s 25% of the total.

Each of these repositories contains a zip archive with a Trojan.

These repositories have been around for many months, some even for over a year, and GitHub does not automatically detect and delete them.

I’ve published a complete list of these repositories on GitHub.
A script for finding such repositories: Git Malware Finder

Open Questions

  1. Why do they only clone new repositories, rather than popular ones?
  2. Why do they delete a commit and push a new one every few hours?
  3. Why doesn’t GitHub automatically detect such repositories?
  4. What exactly does the executable exe file from the archive do?
  5. What is the actual scale of this campaign?

My Hypotheses

The hackers’ goal is to understand how the system works, find its limitations and vulnerabilities, and exploit that information. If overwriting commits helps bypass GitHub’s security algorithms, then that’s what they did. Perhaps that’s also why every commit is named “Update README.md”.

The second goal is to spread the virus. How do they get people to find and download it? I think they do this by cloning only new repositories, which immediately appear at the top of search engine results for low-volume search terms. They also add these repositories to popular GitHub tags to increase the chances of indexing and to help people find them through those tags.

But why do they copy all the commits and contributors? After all, they could have just copied the entire source code. This is likely done to build trust. When someone visits a repository, they see the contributors, can click through to their profiles, and see that these aren’t one-day accounts. And the commit history is preserved so it’s clear that the repository didn’t just appear yesterday. But perhaps this is also done to bypass GitHub’s algorithms.

These are just my assumptions, but the reality may be completely different.

Conclusion

I was subject to GitHub’s API limit of 5,000 requests per hour. I optimized the script to search only for relevant repositories, and I think that because of the filter, the script found only a small percentage of repositories. The GitHub team does not have such limitations. They can analyze all 500 million repositories, find any archives or executable files within them, and scan them for viruses.

This time, I won’t be sending a request to GitHub. There are simply too many repositories. If any of you have direct contact with GitHub’s security team, please send them a link to this article.

* Update
I found this article from April 18: How 109 Fake GitHub Repositories Delivered SmartLoader and StealC
It explains in detail how this Trojan malware works. At that time, the author had found 109 such repositories.

* Update 2
GitHub has started deleting all the repositories that the script found. Most of these repositories have already been deleted.

* Update 3
I found a post on Reddit that mentioned this scheme. It was posted in February 2025, almost 1.5 years ago: If you’re creating new repositories, they are being spoofed to host malware

* Update 4
GitHub deleted only the repositories I listed in the complete list in a txt file. Then I ran the script again, it found new repositories, and I added them to this article. 14 days have passed, and these repositories have not been deleted. GitHub has no way to search for these repositories. They didn’t run my script, and they didn’t write their own script. They didn’t even open this article to see if the list of repositories had changed. They only delete repositories that are reported to them, but they don’t do anything else. That’s why this scheme has been going on for several years now, and will most likely continue.

* Update 5
Someone sent me this article: The rise of malicious repositories on GitHub. In it, the author identified the same pattern for distributing zip archives. Just enter “path:README.md /software-v.*.zip/” into the GitHub search bar, and you’ll get a list of such repositories. What’s noteworthy is that some of them haven’t been updated in half a year, while others are forks of other repositories. But more importantly, I saw repositories in the search results where the readme was updated just 30 minutes ago. Can you believe it? The GitHub team doesn’t even need a script. They can find these repositories with a simple search.

* Update 6
Another article: FakeGit: LuaJIT malware distributed via GitHub at scale. It provides a detailed account of the stages in the development of this scheme, from the initial deployment of the smart contract in March 2025 to the present day. It also includes a detailed analysis of the entire infrastructure, IP addresses accessed by the Trojan, and the hashes of the archives with links to VirusTotal.