I got a mongodb server which from the logfiles seems to have accepted a connection from a remote ip address, though its obviously not allowed due to the mongodb configuration file as shown below.

So, the question is: How can I identify the leak where they got initially in and what steps do I need to do in order to collect more informations to prevent this attack on a new fresh os deploy?

I got a mongodb server which from the logfiles got a connection from a remote ip address, though its obviously not allowed (or to be more precise: the mongod is not bound to any public interface) due to the mongodb configuration file as shown below.

So, the question is: How can one get with a public ip address to the mongodb server? They seem to got ssh access because of various facts below but even then they would need to use the local interface to connect to mongodb, right?

• /var/log/auth.log has been removed inside the mongodb docker container (or it didn't exist yet, because I did not directly ssh to the docker containers), but it still exists on the deamon parent machine though it starts at Apr 24 06:25:29 so I assume they removed it.
• they left a READ_ME (empty) folder & PLEASE_READ_ME folder inside the mongodb root directory, with a file "./PLEASE_READ_ME/collection-0-*****.wt" (masked) starting with the following message: Don't panic. Your DB is in safety and backed up (check logs). To restore send 0.1 BTC and email with your server ip or domain name. Each 48 hours we erase all the data...
• they did not create additional db users (or at least, additional users do not exist atm)

• /var/log/auth.log has been removed inside the mongodb docker container (or it didn't exist yet, because I did not directly ssh to the docker containers), but it still exists on the deamon parent machine though it starts at Apr 24 06:25:29 so I assume they removed it.

• they left a READ_ME (empty) folder & PLEASE_READ_ME folder inside the mongodb root directory, with a file "./PLEASE_READ_ME/collection-0-*****.wt" (masked) starting with the following message: Don't panic. Your DB is in safety and backed up (check logs). To restore send 0.1 BTC and email with your server ip or domain name. Each 48 hours we erase all the data...

• they did not create additional db users (or at least, additional users do not exist atm)

• this is the list of the service on the parent machine (netstat)

  tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1281/sshd
  tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1296/exim4
  tcp 0 0 0.0.0.0:54885 0.0.0.0:* LISTEN 707/rpc.statd
  tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 697/rpcbind
  tcp6 0 0 :::22 :::* LISTEN 1281/sshd
  tcp6 0 0 ::1:25 :::* LISTEN 1296/exim4
  tcp6 0 0 :::35619 :::* LISTEN 707/rpc.statd
  tcp6 0 0 :::27017 :::* LISTEN 1172/docker-proxy tcp6 0 0 :::111 :::* LISTEN 697/rpcbind
  udp 0 0 127.0.0.1:883 0.0.0.0:* 707/rpc.statd
  udp 0 0 0.0.0.0:39217 0.0.0.0:* 707/rpc.statd
  udp 0 0 0.0.0.0:872 0.0.0.0:* 697/rpcbind
  udp 0 0 0.0.0.0:111 0.0.0.0:* 697/rpcbind
  udp6 0 0 :::49550 :::* 707/rpc.statd
  udp6 0 0 :::872 :::* 697/rpcbind
  udp6 0 0 :::111 :::* 697/rpcbind

So, the question is: How can I identify the leak where they got initially in and what steps do I need to do in order to collect more informations about the attack?

So, the question is: How can I identify the leak where they got initially in and what steps do I need to do in order to collect more informations to prevent this attack on a new fresh os deploy?