<?php
// contact form -> Zoho CRM lead
add_action('wp_ajax_nopriv_mbs_lead', 'mbs_lead');

Case study · Security · Linux · WordPress

The malware kept coming back. Here is why.

A hosting account was quietly running encoded shell commands every hour. Cleaning files would not have been enough; the job was to find every way the attacker had planned to return.

Delivered · verified clean

Symptomhourly cron · Base64 shell
Scopeaccount vs root compromise
Persistenceobject-cache.php · 2 cron hooks
VerifyIOC scan clean
Recoverreboot · kernel recovery

1Malicious system cron job
1Malicious drop-in file
2Malicious WordPress cron hooks
0Indicators left after the scan

The problem

A cron job in the hosting account ran Base64-encoded bash commands every hour. Whatever it downloaded, it would download again.

The first question was not "which files are infected" but "how far does this go": the hosting account only, or the whole server.

What I built

Scoping
Separated an account-level compromise from a root-level one, which decided how deep the cleanup had to go.
Cron cleanup
Found and removed the hourly job running the encoded commands.
Drop-in persistence
Removed a malicious wp-content/object-cache.php, a file WordPress loads automatically on every request.
WordPress cron hooks
Removed two malicious hooks in WordPress's own cron that could reinstall the payload.
Verification
Ran an indicator-of-compromise scan, which came back clean.
Recovery
Rebooted the server and recovered the kernel, then documented the follow-up items.

Key decisions

Decision 1
Scope before cleaning
Knowing whether root was compromised changes everything that follows.
Decision 2
Hunt persistence, not just files
System cron, WordPress cron and drop-ins are where reinfection hides.
Decision 3
Verify with evidence
A clean IOC scan, not a feeling, closed the incident.
Decision 4
Write down what is left
Remaining follow-up items were listed instead of being declared done.

Where it stands

The persistence mechanisms were removed, the IOC scan came back clean and the server was recovered. Some follow-up hardening items were documented for after the incident.

The same approach, logs and evidence before changes, also solved a different kind of problem on another store: one payment plugin making more than 11,000 requests to its own site. Removing it brought the CPU back to idle.

Stack

Compromised hosting account

Layer: Linux server, hosting account, WordPress
Found: System cron, Base64-encoded bash, object-cache.php drop-in, WordPress cron hooks
Tools: Log review, IOC scanning, cron inspection
My role: Investigation, cleanup and recovery

The malware kept coming back. Here is why.

The problem

What I built

Scoping

Cron cleanup

Drop-in persistence

WordPress cron hooks

Verification

Recovery

Key decisions

Where it stands

Stack

More case studies

Event hotel booking platform

Pickup portal on Zoho CRM

B2B lead intelligence pipeline