How We Traced and Stopped a UDP Flood Attack on an Oracle‑Tomcat Server

Background

On the first day of the Chinese New Year the client reported that their Oracle + Tomcat server was unreachable. Network inspection revealed an enormous UDP flood that saturated the bandwidth, causing a complete service outage.

0×01 Finding the Trojan

After SSH‑login we used top and spotted a suspicious process named gejfhzthbp. The command lsof -c gejfhzthbp showed external TCP connections that hinted at a possible reverse shell.

Further investigation with

whereis  gejfhzthbp
ls -al  gejfhzthbp

revealed the file’s path and timestamps that matched the intrusion time. The file was copied to a Kali VM for testing, confirming its malicious behavior.

0×02 Restoring Service

Attempting to kill the process proved difficult because it respawned under different names. Various ps -ef | grep checks showed parent processes alternating among sshd, pwd, ls, and even a VNC session. Ultimately we hardened the server with iptables rules:

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp -d 192.168.1.235 -j ACCEPT

iptables -A DROP

These rules allowed local traffic, established connections, and specific outbound traffic while dropping everything else, restoring normal operation.

0×03 Investigating the Root Cause

The underlying issue was weak SSH security. By examining /var/log/secure we discovered that after a year‑end equipment upgrade the server was left with a simple password for convenience, which an attacker from an Indonesian IP brute‑forced. The attacker then changed the root password, locking out legitimate users.

cd /var/log
less secure

Further log analysis and command history showed the attacker’s scripts and actions, leading to the recommendation of a full system reinstall.

0×04 Postscript

The author acknowledges limited Linux operations experience and suggests that a thorough cleanup or reinstall is the safest path forward.