Warning and GCE instance lock

[Hashiba Iwao]

Hello,

I setup ubuntu VM instance on GCE, and after setting up SSH connection, I left the VM running.

And in the mid-night(AM1:13), I received warning e-mail from google compliance which indicate my VM was locked because google detected my VM had been used for mining cryptmoeny. 

And after 2 hours(AM3:15), I received email from google compliance which indicated my VM was unlocked "according to information provided by you".

These 2 emails was received while I'm sleeping and I noticed these e-mails next day.

I checked my account activity, and confirmed no activity than me. I(or someone who might hacked my account) had not provided any information between the 2 hours.

I also checked cost manager on GCE, and confirmed some small charges of "Network Internet Egress from Japan to XXX". There were variety of XXX, US, Austraria, China, Netherland etc.

I thought these charges seemed to be because I left SSH port as default 22, so I changed it.

However, I wonder if these access from other region can be detected as "mining" by Google. 

Does anyone have similar situation?

My account password is more than 20characters, so I believe no one was possible to access either google account or local user of Ubuntu before setting root password.

I would like to know how google determined my account "escaped from problem situation".

Iwao

[Digil (Google Cloud Platform Support)]

Usually, when a GCP project or VM got suspended as a result of violation to the Acceptable Use Policy an appeal is needed as per the 'Policy violation FAQ'. So in your case, it is highly possible that someone could have appealed on your behalf. I therefore, suspects an act of hacking on your project. 

If you believes that the instance had undergone any DDoS attack or hacked, there are some documentation available on avoiding the DDoS attack. You may need to refer these documentations for the best practices to avoid the DDoS attack. If you suspect a malicious activity in the traffic, you may need use the Cloud Armor to protect the instance.

Mentioned below are the best Practices that you could follow to secure the instances in future to avoid these type of unwanted situations.(below mentioned practices are from best practice guide)

1.- Connect securely to your instance. For externally facing applications, it's a good idea to configure your firewalls properly and secure your ports.

2.- Ensure the project firewall is not open to everyone on the internet. Leaving all firewall rules open to 0.0.0/0 will mean that any source on the internet can establish a connection to your instance. Unless you specifically want to make your instance publicly available, a general best practice is to allow access only to your application, and only on the ports your application needs access to. For best practice information about firewalls, see Firewall rules links from best practice guide.

3.- Use a strong password. Passwords ensure that only authorized people have access to your instance. For information on creating strong passwords, see Creating a strong password. In addition, remember to secure the Gmail account that you use for accessing the Cloud Platform Console. For tips on securing your Gmail account, see Gmail security checklist.

4.- Ensure that all software is up to date. Make sure that the software you have installed is up to date and that there are no known vulnerabilities that could compromise your instance.

5.- Monitor project usage closely via the monitoring API to identify abnormal project usage. Google Cloud Platform offers Cloud Logging. Cloud Logging enables you to collect and store logs from applications and services on the Google Cloud Platform. You can use logging to create log-based metrics for monitoring and alerting on unusual behavior. For more information, see the Cloud Logging Documentation. Investigate any suspicious usage to ensure that your instance is not being hijacked by malicious software.

6.- Ensure that your service accounts have just the necessary permissions. Please, verify the roles of these service account and consider recreate them with new roles and keys if these are necessary.

Here, one of my other recommendation for you is to stop your instance, if you have a snapshot(ie one created before the attack) of the instance you should be able restore the GCE VM using that snapshot.