-
@ Fabio Manganiello
2025-03-04 21:39:21
If you run a #Drone CI server, set DRONE_REGISTRATION_CLOSED=true (and manually create users only when you really really trust someone).
The CPU on my CI/CD server suddenly spiked to 100% today.
A closer look found some users who had registered on git.platypush.tech and on the CI/CD server and created a repo with a .drone.yml, a .gitlab-ci.yml and some scripts with base64-encoded commands.
The repo also contains a deepCC.ipynb Jupyter notebook that downloads some training data from S3 and uses Tensorflow to train a model, and then uses the deepCC binary to do something with that model.
The repository also has a configure script with base64-encoded commands that seem to configure a miner (the wallet ID is R9WpFbvkb6dep6bfLdbpcyz3LpMeikUL6W and the coin is VRSC, if anyone is interested in investigating further).
The deepCC binary is itself quite big (~50 MB), and a look at what the setup script does reveals that it’s actually a .tar.gz archive with a larger binary inside.
A quick run of strings on the binary confirms that it’s actually a miner - it connects to eu1-etc.ethermine.org and it also has a bunch of CUDA bindings to run on GPUs.
I still don’t get what’s the point of the Jupyter notebook that trains a model and passes it to this miner, but if you feared the day of the arrival of the zombie Docker containers that exhaust system resources by mining cryptocrap AND training AI models, well, I’m afraid to inform you that that day has come.
If you are a #Gitea / #Forgejo admin, take a look at the users and repos created in the past couple of weeks. Check in particular if any recently registered users have created a repo named deepcc-v.
The most likely authors are users named farzanfarid16 and zurizoey0.
A quick search confirms that both these users are registered on gitea.com too and have already created the incriminated repo:
https://gitea.com/farzanfarid16/deepcc-v
https://gitea.com/zurizoey0/deepcc-v
And if you are a Drone CI or #Gitlab admin, check if any of these users have also started CI/CD pipelines connected to that repo.
For now, disabling the execution of CI/CD pipelines unless a user has been explicitly authorized is the best idea that comes to my mind.