Hello after days of frustration finally i discovered a rootkits that grant shell access to my sites on my Droplet. I discovered it because, spammer delete admin account on one of my sites. (all wordpress)
I deleted all file created but still file recreated few minutes after deletion
Please how i can stop this? Any help will be appreciate
Thank you
If it has given shell access, then it could have installed anything, anywhere on your server. It is possible to clean up, but probably easier just to go back to a previous backup or reinstall the server.
Just removing the file, doesn't fix the problem - you need to make sure everything is up-to-date and setup in a secure way. And be aware of bad/outdated plugins/themes in WordPress.
before try make new droplet i want try remove all malware, just now i start a scan with clamscan, but i have not set password for access to droplet i just use a private ssh key
this is one of the script i found: https://code.google.com/archive/p/b374k-shell/
I found this in auth log
Mar 2 13:45:38 localhost sshd[4525]: Invalid user billing from 115.28.110.195
Mar 2 13:45:38 localhost sshd[4525]: input_userauth_request: invalid user billing [preauth]
Mar 2 13:45:38 localhost sshd[4525]: pam_unix(sshd:auth): check pass; user unknown
Mar 2 13:45:38 localhost sshd[4525]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.28.110.195
Mar 2 13:45:41 localhost sshd[4525]: Failed password for invalid user billing from 115.28.110.195 port 53260 ssh2
Mar 2 13:45:41 localhost sshd[4525]: Received disconnect from 115.28.110.195: 11: Bye Bye [preauth]
Mar 2 13:45:42 localhost sshd[4523]: reverse mapping checking getaddrinfo for ppp-102-146.24-151.wind.it [151.24.146.102] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 2 13:45:44 localhost sshd[4523]: Accepted publickey for root from 151.24.146.102 port 64216 ssh2: RSA 7c:0d:d9:a6:82:8b:56:e4:13:1a:d0:38:49:45:28:78
Mar 2 13:45:44 localhost sshd[4523]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 2 13:45:44 localhost systemd-logind[806]: New session 3 of user root.
Mar 2 13:47:39 localhost sshd[4617]: Invalid user ftp from 123.59.134.76
Mar 2 13:47:39 localhost sshd[4617]: input_userauth_request: invalid user ftp [preauth]
Mar 2 13:47:39 localhost sshd[4617]: pam_unix(sshd:auth): check pass; user unknown
Mar 2 13:47:39 localhost sshd[4617]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.59.134.76
Mar 2 13:47:42 localhost sshd[4617]: Failed password for invalid user ftp from 123.59.134.76 port 43310 ssh2
Mar 2 13:47:42 localhost sshd[4617]: Received disconnect from 123.59.134.76: 11: Bye Bye [preauth]
When it comes to WordPress, the majority of breaches are the result of:
...
The first step I would take is to make sure WordPress is updated to the latest release -- then do the same for all plugins and themes. That should, at the very least, patch any known issues.
If after the above is done, you're still seeing someone break through, then I would recommend taking a close look at directory and file permissions. All directories should have a chmod of 755 and all files a chmod of 644.
If any files or directories are using a chmod of 777, that's an issue as that allows for global read, write, and execute (i.e. if anyone can get a file in one of those directories, they could do exactly what the attacker is doing now -- upload a file, execute it, download content, and perform any allowed commands using PHP's built-in system() function, or one of many others).
You can quickly change directory and file permissions by using something like:
find /path/to/wordpress -type d -exec chmod 0755 {} \;
and
find /path/to/wordpress -type f -exec chmod 0644 {} \;
Where /path/to/wordpress is the direct path to your WordPress installation (i.e. where index.php is).
Note, this won't stop that script from changing permissions, so ideally, I would stop Apache, which will prevent script execution since the website will not longer be available due to the web server being down -- then clean up instances of that script, then run the commands above to change file and directory permissions, and then restart Apache to bring the site back up.
...
If it turns out that everything is updated (WordPress, plugins, and themes) and changing permissions did not help after a clean-up, then there may be a bigger issue, but the above will get you started.