Suspicious domains in the Host Database

quietFinn

Well-Known Member
Feb 4, 2006
1,668
341
438
Finland
cPanel Access Level
Root Administrator
I also noticed that the "Normal Shell" tick is enabled by default for the newly created user. While in "Feature Manager", "SSH Access & Terminal" option is not enabled.
That is normal in CloudLinux server, read here:
 

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
That is normal in CloudLinux server, read here:
Thanks, but according to this quote at the same link:

During CageFS package installation or update, all users with jailshell enabled will have it changed to regular / bin / bash in / etc / passwd .
Said "all users with jailshell enabled will have it changed to regular /bin/bash" And not all users whose shells are disabled.

And also even when I disabled the CageFS in Cpanel. New user created, Normal Shell access enabled!
 
Last edited:

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
If you've already confirmed the server is compromised and there are odd files across multiple accounts, there isn't really a point in doing any other troubleshooting. You'll want to get the accounts migrated to a new machine to eliminate the compromise.
But I do not think this solution will be useful, because by transferring accounts, malicious files are also transferred to the new server.
 

ejsolutions

Well-Known Member
Jan 6, 2013
77
32
68
cPanel Access Level
Root Administrator
.. by transferring accounts, malicious files are also transferred to the new server.
Not necessarily an issue, IF you bolster the security on the server PRIOR to transferring the accounts. Jailed accounts should mean that even if an account is compromised, it will not traverse accounts nor corrupt the server. (That's the whole purpose of Jailing accounts) This should buy you time to further investigate where the hack occurred.
If you should get hacked again, then I'd go knocking on the door of Cloudlinux - it's what you pay them for.
just my opinion on the matter. ;)
 
  • Like
Reactions: NabiKAZ

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
11,780
1,872
363
cPanel Access Level
Root Administrator
If there are files at the account level causing an issue, those would be transferred to the new machine. We always recommend performing a transfer when there is a root compromise since there is no way to ensure a system is secured after malicious root access.

As @ejsolutions said, keeping the accounts jailed with CloudLinux should keep any compromises from infecting other accounts on the machine.
 

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
According to your suggestion and friends above.

1. full backup from all accounts by cpanel.
2. back up system files by cpanel.
3. format disk.
4. install CloudLinux 8 & cpanel
5. restore accounts.

Is this roadmap approved?
Given that I now have cloudlinux 7.
Also I have more doubts about option 3 in terms of security.
 

ejsolutions

Well-Known Member
Jan 6, 2013
77
32
68
cPanel Access Level
Root Administrator
I'd do a full fdisk (clearing filesystem signatures) and LVM remap, rather than just a format. If you go the same server approach.
Also, add CSF and mod_sec, plus run the two security advisors on the server, before account restores. That takes me about a full days work to do!
As per @cPRex a 'fresh' server is best, so that other accounts aren't down during the course of a build/rebuild.

Note: I tried CL8 during a recent update and had to revert back to CL7 - numerous niggly problems that I didn't have the time/energy to resolve.
 
Last edited:
  • Like
Reactions: NabiKAZ and cPRex

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
That seems like a lot of work and isn't the way I would do things. I would just create a new machine and transfer the data over with the WHM >> Transfer Tool.
I know about the Transfer Tool and I can consider a new disk but it is not interesting since I have to consider a new IP with a new CPanel license.
I know my method is down time but it is not a problem and I do it in low traffic time.

Now the question I have is that to transfer the settings and configuration of the server, if I use the "Backup Configuration > Back up System Files" CPanel, will the malicious files with them not be transferred to the new server?
 

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
And I have another question, is there a special type of configuration in Cpanel that works with PHP with access level USER:USER and 0755 on public_html and sets this access itself?
 

ejsolutions

Well-Known Member
Jan 6, 2013
77
32
68
cPanel Access Level
Root Administrator
Backup Configuration > Back up System Files
Personally, I wouldn't do this (for your reasons) and instead perhaps screenshot the important settings, or otherwise take a note. Also, you may inherit deprecated settings - best to use 'vanilla' settings then add flavouring. ;)
USER:USER and 0755 on public_html
This is standard fare on my WHM/cpanel setups and indeed on other servers, with different control panels. Refer to mod_suexec, suPHP (preferably PHP-FPM).
 
Last edited:
  • Like
Reactions: cPRex and NabiKAZ

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
I scanned all the servers except the /home path that contained the accounts with clamscan and the result was as follows:

Do you think there is something more suspicious than the others that I need to put under a magnifying glass?

Code:
/usr/local/src/maldetect-current.tar.gz: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/clean/gzbase64.inject.unclassed: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/cpanel/3rdparty/share/clamav/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/cpanel/3rdparty/share/clamav/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/cpanel/3rdparty/share/clamav/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/cpanel/Whostmgr/Pkgacct/3rdparty/mbx2mbox/mailutil: Unix.Tool.Flood-9941210-0 FOUND
/usr/local/maldetect/clean/gzbase64.inject.unclassed: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share/clamav/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share/clamav/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share/clamav/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/Whostmgr/Pkgacct/3rdparty/mbx2mbox/mailutil: Unix.Tool.Flood-9941210-0 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 8635509
Engine version: 0.104.3
Scanned directories: 96587
Scanned files: 488074
Infected files: 102
Total errors: 16157
Data scanned: 25927.35 MB
Data read: 80705.52 MB (ratio 0.32:1)
Time: 34490.078 sec (574 m 50 s)
Start Date: 2022:06:24 22:27:27
End Date:   2022:06:25 08:02:17
 

ejsolutions

Well-Known Member
Jan 6, 2013
77
32
68
cPanel Access Level
Root Administrator
^ A quick glance and they look like false positives. Good on you for using maldetect though.
Personally, I wouldn't "risk it for biscuit" and wouldn't waste time: go straight for a freshly installed server, prepared as mentioned, then restore user accounts.
You could've had it completed by now! :-p
 
  • Like
Reactions: NabiKAZ

Michael-Inet

Well-Known Member
Feb 20, 2014
134
20
68
Nashville, TN, USA
cPanel Access Level
Root Administrator
Do you think there is something more suspicious than the others that I need to put under a magnifying glass?
NabiKAZ,

Since we had similar issues, I'm guessing you installed a "shared cPanel" license. The website I purchased one from implied they were a cPanel partner and authorized to sell 'legal' shared licenses. After this thread I did some digging and found out that, that is most likely not the case and "shared cPanel" licenses are a hack and apparently just stealing from cPanel though some proxy mechanism. They also are suppose to give complete root access to your box to the shared license seller. (Which would make sense as you run an install script from then as root to setup the proxy 'stuff.')

As I had no client data on the box (testing server), my method was to re-install from scratch and manually re-create the account(s).

If there had been client data, I would have offsite backed up just the client data. Rebuilt the server, manually re-created the accounts/domains, and then moved the client data back to where is should be.

HTH,
Michael


@cPRex, PM me if you want the website I purchased from.
 
  • Like
Reactions: NabiKAZ

NabiKAZ

Active Member
Jun 18, 2007
31
1
58
I came across another security point.
I installed only nginx on another clean centos7 server (without Cloudlinux) with cpanel:
Home / Software / NGINX® Manager / Install NginX
I noticed that the access level of all accounts to USER:USER 0755 changed and there was access to another account from each account.
If you uninstall nginx and click install again, the same thing will happen again.
It does not seem normal to make such unsafe and dangerous settings by default. And it can be a dangerous bug. Maybe I got hit from here!