Detecting a Hidden Mining Virus in a Linux System: A Narrative

This story, adapted from a previous mining‑virus incident, portrays a tense evening in a Linux "empire" where an alarm sounds and CPU usage suddenly spikes, prompting the security chief to convene an emergency meeting.

The chief asks the kill command to call on top to identify the offending process ID, but top can only display the current process list, which appears normal.

Next, the ps command also lists processes but finds nothing suspicious, leading the security chief to question why both tools cannot see the culprit.

They discuss that both top and ps traverse the /proc/ directory using opendir/readdir system calls, which might be filtered by a compromised kernel.

The netstat command suggests calling a friend named unhide , a tool specialized in finding hidden processes, and also checks for any suspicious external connections.

netstat prints the current network connections, showing several known services (nginx on port 80, redis on 6379, elasticsearch on 9200, etc.) and one unclaimed connection:

tcp   0    0 192.168.0.4:51854      88.99.193.240:7777    ESTABLISHED  -

The security chief asks curl to probe the remote IP, which returns a response containing the phrase "mining poll", indicating a mining virus.

The firewall blocks the suspicious connection, and unhide is summoned. Using a different scanning method—iterating PID numbers from smallest to largest and checking each /proc/$pid directory— unhide discovers hidden processes:

Found HIDDEN PID 13053
    Executable: "/usr/bin/pamdicks"
    $USER=root

Found HIDDEN PID 13064
    Executable: "/usr/bin/pamdicks"
    $USER=root

Further analysis shows that the hidden process has an open socket in /proc/pid/fd matching the previously observed port 7777, confirming its identity.

After backing up the malicious binary with cp , the team uses kill and rm to terminate and remove the process, after which CPU usage returns to normal.

Despite the cleanup, the security chief remains uneasy, fearing how the hidden process entered the system and who might be protecting it. The alarm sounds again, hinting that the threat may not be fully eradicated.

The article concludes with a call to follow the author for more technical stories.