Curious how you resolved this?

[mfurlend]

I'm having the same exact issues. What did you do to prevent this? The directory keeps showing up every week.

[dangoldin]

Hmm. I don't recall the exact details but did a writeup/analysis of this on https://dangoldin.com/2020/05/29/anatomy-of-a-crypto-mining-hack/ so that might provide some info.

I think I had to remove the folder itself but also some of the initial processes/files by tracing it backwards.

[mfurlend]

Thanks for the reply. Interestingly, the ssh key in your analysis is the exact same one that I encountered.

[dangoldin]

I'm surprised the hack is still going on. Were you able to trace it back to a source? I do think that origin script was in another folder but don't recall which one. You can try running "ps -a" to see the processes running and also check out your cron file to see if anything got automatically scheduled there.

[aaabhilash97]

Any idea how this got installed in machine?
My server not allowing ssh from public ip

[sibidharan]

We got the same attack today. We recovered it successfully and stopped the attack as users complained the site was slow. In our case they got root access. Is there some info on how they got in the first place?

[sibidharan]

Any idea how this got installed in machine?
My server not allowing ssh from public ip

Go to your server, boot with live cd, access shell and change your key back.

[aaabhilash97]

@sibidharan no idea how it got installed in first place. We terminated machine immediately, so couldn't able to troubleshoot.

It might be some vulnerable packages you installed or ssh key or password is compromised.

[dangoldin]

Yea - I think what caused it for me was installing an sftp package that I was lazy in configuring so it exposed a vulnerability that gave them access. It's pretty hard to do a deep clean since you always wonder if you got something. If easy I'd suggest just rebuilding and creating a new instance.

[sibidharan]

In my case, it looks like a vulnerability in our gitlab instance. We notice the moment the attack happened, changed ssh key via live boot CD and got access back and ran a full scale backup on gitlab and restored it in a new machine. We are investigating the old server, keeping it live at time moment, by completely isolating it.

[aaabhilash97]

@sibidharan
Please update here if you find anything in your investigation.

In our case, if I remember correctly, they gained access to a non-root user account on a machine where we were running some Python applications. We could have isolated the machine and investigated further, but we made a mistake and terminated the machine.