What to do if your server is hacked

Quick answer: Isolate the server (firewall block or power it off from the Client Area), assess through the KVM Console, preserve evidence, rotate every credential from a clean device, then rebuild: reinstall the OS and restore data from a backup made before the compromise. Cleaning a rooted system in place is rarely trustworthy.

Overview

Once an attacker has had root, every binary, cron job and account on the box is suspect. The professional playbook is contain → investigate → rebuild, in that order. Speed matters twice: to limit damage to your data, and to stop the server attacking others — which is also an abuse policy matter.

Before you start

• Access to the Client Area (power controls, KVM Console) from a device you trust.
• Your latest clean backup and its date.
• A clean machine for all recovery work — assume your usual keys/passwords may be stolen.

Step-by-step guide

1. Contain: block all inbound/outbound traffic except your admin IP at the firewall, or stop the server from the service page if it is actively attacking others.
2. Assess via KVM Console: look for unknown users (/etc/passwd), processes (ps auxf), sockets (ss -tulpn), cron entries, SSH keys in authorized_keys, and entry hints in auth logs and web logs.
3. Preserve evidence: copy relevant logs off the server before wiping if you need root-cause analysis or a report.
4. Rotate credentials from the clean device: Client Area password, SSH keys, application secrets, database and API keys — anything the box knew.
5. Rebuild: reinstall the OS, harden it (checklist), patch the entry-point vulnerability, then restore application data from a pre-compromise backup — see also the recovery-focused guide.
6. Verify before going live: updated packages, no restored web shells (scan the restored data — malware scan guide), monitoring in place.

Common issues

• Deleting the malware and moving on: persistence survives in cron, systemd units, SSH keys and patched binaries — rebuild instead.
• Restoring an infected backup: scan restored content and pick a backup from before the intrusion date.
• Not fixing the entry point: the same vulnerable plugin gets re-exploited within days.

When to contact support

Notify Cloud2Y support if the server sent abuse (spam, scans, floods), if you received an abuse notice, or if you need power/KVM help during containment. Proactive communication keeps the recovery cooperative rather than enforcement-driven.

Frequently asked questions

What is the very first step after discovering a hack?

Containment: block traffic at the firewall except your admin IP, or power the server off from the Client Area if it is actively attacking others. Investigation comes after isolation.

Can I just remove the malware and keep running?

It is risky — attackers with root leave persistence in cron jobs, systemd units, SSH keys and replaced binaries. A clean OS reinstall plus restored data is the only trustworthy state.

Do I have to tell Cloud2Y that my server was hacked?

If it sent spam, scans or floods — yes, proactively via ticket. Compromised servers fall under the abuse policy, and cooperative handling is far smoother than an enforcement response.

Related articles

• What to do if your server is compromised
• How to scan a server for malware
• How to read auth logs
• Abuse policy and prohibited activities

Need a hand? Contact Cloud2Y support →