Seitenhistorie

...

• Unexplained reboots.
• rkhunter reporting the libncom rootkit.
• Presence of files in /tmp like do, update, rc_local_found.
• Presence of files in /usr/bin like minerd, or starting with _- (underscore-dash - these should apparently be hidden by the rootkit).
• Presence of /lib/libncom.* or /lib64/libncom.* and /etc/ld.so.preload pointing to this library (beware of the rootkit, see above).
• CPU usage that can't be accounted for. The miner process might only be visible when evading the rootkit (see above).
• Presence of /usr/local/bin/ssh.
• Some tools may have been upgraded or installed (gnu auto*, Python, JRE), metasploit, nmap.

On the backup

With some luck, the backup logs may show when files were created or altered, even if they have been removed since. Things to watch for are e.g.:

• minerd,* 
• ssh
• ld.so.preload
• _-* (anything that starts with underscore - dash)
• automake, autoconf, ...
• wangyin*

Any findings in the backup log can also help establishing a timeline.

...

To avoid detection, the libncom rootkit is installed. From this point on detection may be difficult, allthough the rootkit doesn't seem toalways work properly.

A number number of directories and files were touched during installation of various software. Places to look at are /tmp, /usr/bin and /usr/bin, /raid2/, /opt.

In one case (so far), 

• the minerd.gz and some more scripts have been installed in the ftp/http directory.
• metasploit has been used to scan for potential victims.

We are to date not aware of:

• any user accounts being created.
• manipulation of the logfiles.

Remediation

The usual advice is to disconnect and then reinstall the compromised machine. Considering that a rootkit is used and that the system is manually modified by the attackers, this is probably a good advice.

Be careful to close the IPMI/RFB-vulnerability before getting back online, otherwise the attack can be repeated anytime.

Have the users change their passwords on the local machine and, if applicable, on machines they connected to via ssh. Be aware that the attackers could also have copied the private ssh keys, so these keypairs would need to be replaced as well.

Check for possible lateral movement and intrusions of equally vulnerable servers. Make sure IPMI/RFB can't be exploited on any machine.

Countermeasures likely not to be effective:

• changing the root password
• using tcpwrappers (hosts.allow / hosts.deny)
• firewalling ssh while leaving any other services accessible

Contact and Feedback

ACOnet-CERT welcomes feedback, preferably by e-mail to cert@aco.net. If you are aware of other sites covering this topic, please let us know. 

FAQ

Q: What does the name 750x7 stand for?

...