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?
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.
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.
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
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.
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.
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 @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?