How to Diagnose and Remove Hidden Malware Causing Network Flood on a Linux Server

Background

A friend reported that after a server reboot, all machines on the same subnet experienced severe slowdown and remote access to the server was choppy. The symptoms suggested a possible compromise.

Initial Hypothesis

The author first suspected a web‑application attack—weak Tomcat passwords, uploaded WAR or PHP files that generate massive outbound traffic.

Step 1: Verify NIC Traffic

A small shell script was used to sample inbound and outbound bytes every two seconds:

while : ; do
  time=`date "+%Y-%m-%d %H:%M:%S"`
  rx_before=`ifconfig eth0|sed -n "8"p|awk '{print $2}'|cut -c7-`
  tx_before=`ifconfig eth0|sed -n "8"p|awk '{print $6}'|cut -c7-`
  sleep 2
  rx_after=`ifconfig eth0|sed -n "8"p|awk '{print $2}'|cut -c7-`
  tx_after=`ifconfig eth0|sed -n "8"p|awk '{print $6}'|cut -c7-`
  rx_result=$[(rx_after-rx_before)/256]
  tx_result=$[(tx_after-tx_before)/256]
  echo "$time Now_In_Speed: "$rx_result"kbps Now_OUt_Speed: "$tx_result"kbps"
  sleep 2
done

Running sh traffic.sh produced occasional spikes such as:

2016-02-03 13:32:13 Now_In_Speed: 1kbps Now_OUt_Speed: 664567kbps
2016-02-03 13:32:17 Now_In_Speed: 6kbps Now_OUt_Speed: 657895kbps
2016-02-03 13:32:21 Now_In_Speed: 3kbps Now_OUt_Speed: 568462kbps

Step 2: Check Tomcat and Other Services

The webapps directory contained no suspicious JARs. Oracle was the only other service running, so it was stopped to narrow the scope.

Step 3: Examine Running Processes

Using ps -ef revealed many processes; a Tomcat process kept restarting after being killed, indicating a watchdog script.

Step 4: Inspect Init Scripts

The /etc/init.d directory contained two odd files, functions and DbSecuritySpt. Their contents were simple Bash commands pointing to a Tomcat webapp path. After moving them away, the system failed to boot, requiring a remount of the root filesystem and an fsck. After a successful reboot, the Tomcat process was gone, but outbound traffic persisted.

Step 5: Look for PID Files in /tmp

Searches for PID files in /tmp turned up nothing useful.

Step 6: Use Network Tools

Tools like iftop and iptraf were unavailable; screenshots of iptraf output are shown below.

Step 7: Scan Open Ports

Running netstat -an | more revealed a suspicious outbound connection: xxxx.51545 -> 119.147.145.221:6001 The associated process was a getty instance (PID 1587). Killing this process stopped the traffic spikes.

Step 8: Search for Persistent Malware in Init Levels

Examining the /etc/rc.d run‑level directories showed identical malicious scripts placed in each level, along with a mismatched selinux file and a /usr/bin/bsd-port directory. After deleting these files and rebooting, the server operated normally and NIC traffic returned to baseline.

Conclusion and Recommendations

Prefer key‑based SSH authentication over password login.

Close unnecessary ports that are not required for business operations.

Adopt a systematic elimination approach when troubleshooting.

Maintain familiarity with system scripts and processes; consider a clean OS reinstall after a compromise.