How to proceed if my VPS has been compromised at level 5 (Rootkit with kernel/boot persistence)

Bare Metal and VPS
1

Binary /usr/bin/systemds (gsocket / gs-netcat from THC)
Unit systemds.service, described as "D-Bus System Connection Bus", enabled, Restart=always
Process renamed to [ksmd] with exec -a to appear as a kernel thread
Key /lib/systemd/system/systemds.dat
Active since 29-Jul 18:53:51 (4 days)
C2 51.91.190.242:443, permanent outbound connection
It is outbound by design: it uses the global gsocket relay network, so it traverses ufw without opening any port and leaves neither a login in auth.log nor a request in nginx. That's why you spent weeks not finding how they got in — they don't come in, they're already inside and the server calls them to them.

2

Translation?

3

Hello @segoviasoft

The gs-netcat binary is not just any trojan. It is specifically designed to bypass firewalls via outbound connections and does not require inbound open ports.

The systemds process runs as a “systemd” daemon and includes automatic restart to ensure persistence. Additionally, it hides in the process list by masquerading as the kernel thread [ksmd] and the file systemds.dat stores the access key, while the permanent outbound connection to C2 51.91.190.242:443 guarantees the attacker can take control at any time.

I recommend you do the following:

  1. Isolate the server from the network to contain the threat.
  2. Document the evidence before deleting anything. Copy the systemd unit (/etc/systemd/system/systemds.service), the key file (/lib/systemd/system/systemds.dat) and the binary itself (/usr/bin/systemds).
  3. Remove the backdoor manually:
    1. Stop and disable the service:
      systemctl stop systemds.service; systemctl disable systemds.service
    2. Delete the malicious files:
      rm /etc/systemd/system/systemds.service /lib/systemd/system/systemds.dat /usr/bin/systemds
    3. Kill any active systemds process.
  4. Force the attacker out :right_arrow: the backdoor activates when it receives a connection, so the attacker may try to reconnect. Consider a full reinstall and changing all passwords and SSH keys :roll_eyes:

In addition, I advise you to do the following:

  • Review the users' command history ("history") especially for root.
  • Audit system users, check /etc/passwd for possible new accounts.
  • Look for other entry points such as the binary via which gs-netcat, cron jobs, and the user profile file—either .profile or .bashrc.
  • I strongly recommend checking auth.log for connection attempts from IP 51.91.190.242, which belongs to OVHcloud, and also opening a ticket with Support to report that IP.

I hope this helps. Best regards.
Sergio Turpín

4

Hello,

I think there's no need to be technically skilled or ask the AI to understand that the VPS must be completely reinstalled and the data recovered carefully.

There will always remain a doubt that a hidden spy is inside the machine.

5

Yes, reinstalling is always the safest solution and, in the case of an infection of this type, the only guarantee of total cleanliness. That said, I always recommend making a prior backup of critical data, even if just to review it in an isolated environment and rule out that it is also infected.