Cloudzy account suspended without warning: 4 servers offline, no explanation, no way to retrieve dat

ascicode

False positive? Can happen too.

nle2000

@ascicode said:
False positive? Can happen too.

not really 100% it was false positive, or my password or server has been compromised. But the VM password is very hard to predict and im unsure someone has access to my server.

because the Spamhaus' reported it my IP is interacted with the CIBC

144.172.65.13|cibc-authentication.help|2026-09-07 20:20:01 so i dont know what CIBC is; until I found out it was a bank or something relevant.

i cannot say it is false positive from Cloudzy or it is from my server. Because @Hannan explained it came from VM from my Cloudzy (account).

I've never hosting anything beside the wireguard-easy just for personal use.

angstrom

@nle2000 said:

@Falzo said:
I believe a more appropriate approach would be to secure your infrastructure and services properly instead of letting them run unattended with weak passwords and then cry out loud when you get suspended for getting compromised.

Have you reused passwords? Were your customers data endangered? Maybe the provider did you a favor by shutting everything down quickly, before the attackers could spread onto your other systems... ever thought of that?

Hi Falzo,

That VM was only used for testing and has been inactive for several weeks. Our production VMs use strong, high entropy passwords and separate access credentials.

basically, the VM for demo is kind of abandoned VM to me but still paying for.

Okay, but then it sounds like @Falzo was right: you hadn't locked down this particular VM sufficiently well

HostDZire

In my experience, I have always seen clients deny illegal use after a suspension. As a host, we can't really be 100% sure, right?
As a client, you are responsible for keeping a secure password and locking your VPS access, etc.
If it gets hacked from your side and a crime is committed, the provider's only option is to suspend service.

But I still don't agree with locking his whole account without letting him explain.
The provider could have suspended all his services with a notification of the reason.
Locking the whole account comes after that.

nle2000

@angstrom said:

@nle2000 said:

@Falzo said:
I believe a more appropriate approach would be to secure your infrastructure and services properly instead of letting them run unattended with weak passwords and then cry out loud when you get suspended for getting compromised.

Have you reused passwords? Were your customers data endangered? Maybe the provider did you a favor by shutting everything down quickly, before the attackers could spread onto your other systems... ever thought of that?

Hi Falzo,

That VM was only used for testing and has been inactive for several weeks. Our production VMs use strong, high entropy passwords and separate access credentials.

basically, the VM for demo is kind of abandoned VM to me but still paying for.

Okay, but then it sounds like @Falzo was right: you hadn't locked down this particular VM sufficiently well

yes, im not denying for this action (weak password on wireguard-easy), but it is just for the client page (wireguard easy) has weak password (which is my favorite password not admin1234 or admin/admin etc,.., it's my name with some random symbols + habbits) and it also hard to predict as well as i assumed.

but I check the IP array got blacklisted as well from 1 to 254 for Phising site. As I explained, I never hosted any phising site (scamming people aren't my favorite habbits, never my intention).

since the service has been suspended and unaccessible this is my password of the VM which hosted wireguard-easy 4KxFFi639wYAnG and im pretty sure takes a decade to brute-force it or never without the quantom force. i just want to believe a last thing "okay, my server got compromised because i have weak password 4KxFFi639wYAnG"

im just sharing my expression, no harm.

@HostDZire said:
In my experience, I have always seen clients deny illegal use after a suspension. As a host, we can't really be 100% sure, right?
As a client, you are responsible for keeping a secure password and locking your VPS access, etc.
If it gets hacked from your side and a crime is committed, the provider's only option is to suspend service.

But I still don't agree with locking his whole account without letting him explain.
The provider could have suspended all his services with a notification of the reason.
Locking the whole account comes after that.

thank you for sharing, @HostDZire. It's meaningful to me during this time. And my second mistake is to host the production on my personal account tied with the service instead of the company, if i seperated both service in seperate accounts, this incident won't happens.

i agree with the points of locking his whole account without letting him explain. I am down for all the punishment from the provider if I did anything wrong. I just want an explain/reason.

Cloudzy needs atleast:

• Tell the user the reason or an explain
• Disable specific VM for investigation
• Cooperate with the customer for investigation
• Give the decision for the last if everything is settle

I used Unihost as well, if my servers have some suspicious on my server, they send message for me to solve it; otherwise, they will suspend the account. -> everything solve, Unihost Happy, me happy, NO SUSPENSION at the first glance.

Even i'm using $100/month plan from Cloudzy (good enough for production) and other services for months. EAT THE BAN HAMMER right the way -> emailed me for ticket to address the issue -> ticket created just to have a respond "This suspension is non-negotiable and stay suspended" as announcement -> SEE YA.

tommyluo

By default,block the outgong port 25 and open by ticket request.Most of the vps providers do like this.

Arirang

Personally, Cloudzy isn’t a provider I’d use, mainly because I find their pricing misleading.

They advertise “50% off, starting at $2.48,” but the 50% discount supposedly applies only to selected locations.

On top of that, the $2.48 plan doesn’t include an IPv4 address, even though the description mentions a dedicated IPv4.

Once you add an IP address, the total comes to around $60 per year, while the next plan costs just $42 per year.

I really dislike this kind of pricing strategy. It reminds me of the tactics used by big companies like GoDaddy. Cloudzy seems to be heading in the same direction.

nle2000

@Arirang said:
Personally, Cloudzy isn’t a provider I’d use, mainly because I find their pricing misleading.

They advertise “50% off, starting at $2.48,” but the 50% discount supposedly applies only to selected locations.

On top of that, the $2.48 plan doesn’t include an IPv4 address, even though the description mentions a dedicated IPv4.

Once you add an IP address, the total comes to around $60 per year, while the next plan costs just $42 per year.

I really dislike this kind of pricing strategy. It reminds me of the tactics used by big companies like GoDaddy. Cloudzy seems to be heading in the same direction.

i don't have any comments on that; that's the strategy most of the big company used to marketing their products. Put the drama aside, im quite okay with the Cloudzy before. I also have same points as yours about the discount, it's only discounted for region like north america and others are only %20 max only for anually not applied for cheap-ass user like me..

nle2000

@angstrom said:

@nle2000 said:

@Falzo said:
I believe a more appropriate approach would be to secure your infrastructure and services properly instead of letting them run unattended with weak passwords and then cry out loud when you get suspended for getting compromised.

Have you reused passwords? Were your customers data endangered? Maybe the provider did you a favor by shutting everything down quickly, before the attackers could spread onto your other systems... ever thought of that?

Hi Falzo,

That VM was only used for testing and has been inactive for several weeks. Our production VMs use strong, high entropy passwords and separate access credentials.

basically, the VM for demo is kind of abandoned VM to me but still paying for.

Okay, but then it sounds like @Falzo was right: you hadn't locked down this particular VM sufficiently well

UPDATE

Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed. Server hasn't been compromised and it's not relating to my wireguard docker.

Nothing serves the website. TCP 80, 443, 8080 and 8443 refuse connections from the internet. HTTP and HTTPS requests to the domain fail with "Couldn't connect to server". No nginx, Apache, Caddy, lighttpd or PHP is installed, and /var/www does not exist.

@Hannan is actively working with me to resolve the problem directly in the ticket.

zed

@nle2000 said: UPDATE

Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed. Server hasn't been compromised and it's not relating to my wireguard docker.

Nothing serves the website. TCP 80, 443, 8080 and 8443 refuse connections from the internet. HTTP and HTTPS requests to the domain fail with "Couldn't connect to server". No nginx, Apache, Caddy, lighttpd or PHP is installed, and /var/www does not exist.

this is good news but.. am i understanding they didn't investigate at all, just saw a report with the ip and bam suspended your entire account and all services?

oloke

@nle2000 said: Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed.

For reference; this domain was pointing there at least late May 2026 (shortly after it was registered).
https://dnshistory.org/dns-records/cibc-authentication.help.

buggedout

@nle2000 said:

@angstrom said:

@nle2000 said:

@Falzo said:
I believe a more appropriate approach would be to secure your infrastructure and services properly instead of letting them run unattended with weak passwords and then cry out loud when you get suspended for getting compromised.

Have you reused passwords? Were your customers data endangered? Maybe the provider did you a favor by shutting everything down quickly, before the attackers could spread onto your other systems... ever thought of that?

Hi Falzo,

That VM was only used for testing and has been inactive for several weeks. Our production VMs use strong, high entropy passwords and separate access credentials.

basically, the VM for demo is kind of abandoned VM to me but still paying for.

Okay, but then it sounds like @Falzo was right: you hadn't locked down this particular VM sufficiently well

UPDATE

Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed. Server hasn't been compromised and it's not relating to my wireguard docker.

Nothing serves the website. TCP 80, 443, 8080 and 8443 refuse connections from the internet. HTTP and HTTPS requests to the domain fail with "Couldn't connect to server". No nginx, Apache, Caddy, lighttpd or PHP is installed, and /var/www does not exist.

@Hannan is actively working with me to resolve the problem directly in the ticket.

I am actually amazed, dont spamhaus have any checks in place. This way I can point a domain name at any IP....

nle2000

@zed said:

@nle2000 said: UPDATE

Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed. Server hasn't been compromised and it's not relating to my wireguard docker.

Nothing serves the website. TCP 80, 443, 8080 and 8443 refuse connections from the internet. HTTP and HTTPS requests to the domain fail with "Couldn't connect to server". No nginx, Apache, Caddy, lighttpd or PHP is installed, and /var/www does not exist.

this is good news but.. am i understanding they didn't investigate at all, just saw a report with the ip and bam suspended your entire account and all services?

i cant tell, cloudzy said they believed everything regarding what the system told them. Sometimes, humans have to verify the information provided by the computer instead of 100% trusting it.

nle2000

@buggedout said:

@nle2000 said:

@angstrom said:

@nle2000 said:

@Falzo said:
I believe a more appropriate approach would be to secure your infrastructure and services properly instead of letting them run unattended with weak passwords and then cry out loud when you get suspended for getting compromised.

Have you reused passwords? Were your customers data endangered? Maybe the provider did you a favor by shutting everything down quickly, before the attackers could spread onto your other systems... ever thought of that?

Hi Falzo,

That VM was only used for testing and has been inactive for several weeks. Our production VMs use strong, high entropy passwords and separate access credentials.

basically, the VM for demo is kind of abandoned VM to me but still paying for.

Okay, but then it sounds like @Falzo was right: you hadn't locked down this particular VM sufficiently well

UPDATE

Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed. Server hasn't been compromised and it's not relating to my wireguard docker.

Nothing serves the website. TCP 80, 443, 8080 and 8443 refuse connections from the internet. HTTP and HTTPS requests to the domain fail with "Couldn't connect to server". No nginx, Apache, Caddy, lighttpd or PHP is installed, and /var/www does not exist.

@Hannan is actively working with me to resolve the problem directly in the ticket.

I am actually amazed, dont spamhaus have any checks in place. This way I can point a domain name at any IP....

yes, the troller taught me how to suspend competitor by pointing suspicious domain on their host.

nle2000

@oloke said:

@nle2000 said: Someone pointed the A record to my Cloudzy VM with the domain cibc-authentication.help. My server has 443/80 tcp closed.

For reference; this domain was pointing there at least late May 2026 (shortly after it was registered).
https://dnshistory.org/dns-records/cibc-authentication.help.

Spamhaus banned the IP array from 144.100.65.xxx. This IP pool is unusable since then.

Falzo

If it is a VPN / wireguard running, maybe ports and request went somewhere else through it or if the vpn itself was compromised , someone had something running inside the private network and messed with the VPN routes.

That it now doesn't show anymore wouldn't be surprising after it was shutdown for a while.

Try to check the wireguard setup for weird configs.

nle2000

@Falzo said:
If it is a VPN / wireguard running, maybe ports and request went somewhere else through it or if the vpn itself was compromised , someone had something running inside the private network and messed with the VPN routes.

That it now doesn't show anymore wouldn't be surprising after it was shutdown for a while.

Try to check the wireguard setup for weird configs.

i investigated it and no sign of compromised. Sent the detailed report to Cloudzy.