How I Recovered from a Sophisticated WordPress Mobile Redirection Malware

[Rufai]

I figured I'd share this in case it helps someone else. I spent days trying to figure this out because I couldn't find much useful information online, and none of the security or malware removal plugins I tried actually solved the problem.​

Overview​

A sophisticated mobile-specific WordPress redirection malware that redirected visitors to spam sites. The malicious code specifically checked the User-Agent string to detect mobile browsers, then redirected only those visitors to avoid detection by administrators, who usually check sites from desktop devices. At first, I thought it was just a typical WordPress infection, but it turned out to be much worse.

How the Infection Worked​

While digging through the files, I found malicious code injected into wp-config.php. It contained Base64-encoded payloads using eval(base64_decode(...)).

After decoding it, I found that it was:

• Checking whether the visitor was using a mobile device
• Redirecting only mobile users to spam sites
• Injecting hidden scripts from external domains
• Skipping admin, CLI, and API requests to avoid being noticed

Both sites had the exact same payload injected at the top of wp-config.php. The really frustrating part was that every time I cleaned the files, the infection came back within a few hours.

While investigating, I found:

• Backdoor administrator accounts using the sys_ naming pattern and a [email protected] emails
• Backdoor SSH authorized_keys with immutable flags which means the attacker locked the files to prevent removal and the attacker had root-level access to the server at some point, not just WordPress access.

I also found several fake plugins which plugins:

• Copied themselves to wp-content/mu-plugins/ as 01-mu-*.php files (auto-loading, undeletable from dashboard)
• Re-injected wp-config.php on every page load
• Auto-created hidden sys_ admin accounts
• Exfiltrated credentials to a remote server
• Were installed as far months back

Every time I cleaned the site, these plugins would simply put everything back.
After decoding more of the payload, I found a malicious script injection, ak.akam60800.net, a fake domain designed to look like Akamai CDN injecting a script into every frontend page visit to redirect or infect visitors.

After investigation and checking for malicious systemd services, two things stand out:

• defunct.service — described as "D-Bus System Connection Bus", which was a lie. The real D-Bus service is called dbus.service. Which means it was a malicious service masquerading as D-Bus.
• rc-local.service — runs /etc/rc.local on boot, a classic persistence point.

Further investigation revealed that defunct.service was the malware's persistence engine, running a hidden binary at /lib/systemd/system/defunct.dat continuously, restarting every 5 minutes. This is what is reinjecting wp-config.php.

Checking the full service file and the dat file revealed the smoking gun:

• /usr/bin/defunct — the malware binary, disguised as [raid5wq] (a fake kernel thread name)
• /lib/systemd/system/defunct.dat — its config/key file

Checking the dat file and what the binary showed that it is a compiled ELF binary, a sophisticated piece of malware, a cryptominer or botnet agent disguised as a kernel process [raid5wq], and it was actively maintained by the attacker.

Root cause:
A malicious systemd service called defunct.service was running a hidden ELF binary (/usr/bin/defunct) disguised as a kernel thread [raid5wq]. It was continuously injecting a fake Akamai script (ak.akam60800.net) into both wp-config.php files to redirect/infect site visitors, and restarting every 5 minutes.

 

[Panther28]

Damn this some good detective work. Well done, hope you got it sorted?

 

[Campaigns By Mike]

that mobile-only redirect stuff is a nightmare to debug if you only check on desktop... had a client site doing something similar last year and we kept thinking it was cached. once they get root and start messing with systemd or cron jobs, standard wp security plugins are basically useless. honestly at that point it is usually faster to just scrap the vps, setup a clean instance, and import the database/uploads after a heavy audit. thanks for sharing the systemd service name, definitely saving this for the next time a site acts up.

 

[Rufai]

Damn this some good detective work. Well done, hope you got it sorted?

Yeah but it took weeks as the sites kept getting reinfected sometimes after a few days or week when you thought you found the root cause as the attacker had planted a lot of hidden backdoors.

that mobile-only redirect stuff is a nightmare to debug if you only check on desktop... had a client site doing something similar last year and we kept thinking it was cached.

It was indeed a nightmare and there was also a caching level injection too. The malware was stuck in OpenLiteSpeed's server-level page cache (cachedata). When the defunct.service rootkit binary was running earlier, it force-injected that script dynamically. OpenLiteSpeed cached the fully rendered malicious page directly into its system cache directory. Even though we cleaned the malware and the wp-config.php files, the server kept safely serving up that poisoned, pre-rendered version from its internal memory cache folder.
Clearing /usr/local/lsws/cachedata/* completely flushed the memory rootkit out of the loop.

once they get root and start messing with systemd or cron jobs, standard wp security plugins are basically useless. honestly at that point it is usually faster to just scrap the vps, setup a clean instance, and import the database/uploads after a heavy audit. thanks for sharing the systemd service name, definitely saving this for the next time a site acts up.

Yes, wp security plugins and malware scanners were useless, did a lot of audit and monitoring with them but didn't detect anything. And yes, setting up a new VPS was the best option but I just kept it as a last resort as I didn't want the hassle.

 

[robert agency]

Thanks for sharing. this is a good reminder that recurring infections often come from server-level persistence, not just compromised wordpress files.

 

[Rufai]

u gotta burn the whole server down, spin up a fresh instance, and migrate only raw database content and clean uploads

Yeah that would be my last resort.

 

[ads studio]

Good catch, One thing I would tell anyone who has to deal with something like this is not to stop at just cleaning the WordPress files If the infection keeps coming back it is worth looking for deeper persistence mechanisms at the server level because that is often where the real problem is hiding and thanks for sharing the details, this could save someone a lot of time.

 

[Patrikan]

Hi, could you please write a solution to this? I have my website sellket.com also infected but I dont have mu-plugins folder on FTP. The malware also inputs the eval64( script to wp-config.php. Thank you in advance! I am literally crying trying to fix this

 

[Rufai]

Hi, could you please write a solution to this? I have my website sellket.com also infected but I dont have mu-plugins folder on FTP. The malware also inputs the eval64( script to wp-config.php. Thank you in advance! I am literally crying trying to fix this

You should connect via SSH instead. I visited your site and there isn't any redirection.

 

[Patrikan]

You should connect via SSH instead. I visited your site and there isn't any redirection.

Got this, thank you Hope it will not show again You saved my life <3

 

[Euisha]

I figured I'd share this in case it helps someone else. I spent days trying to figure this out because I couldn't find much useful information online, and none of the security or malware removal plugins I tried actually solved the problem.​

Overview​

A sophisticated mobile-specific WordPress redirection malware that redirected visitors to spam sites. The malicious code specifically checked the User-Agent string to detect mobile browsers, then redirected only those visitors to avoid detection by administrators, who usually check sites from desktop devices. At first, I thought it was just a typical WordPress infection, but it turned out to be much worse.

How the Infection Worked​

While digging through the files, I found malicious code injected into wp-config.php. It contained Base64-encoded payloads using eval(base64_decode(...)).

After decoding it, I found that it was:

• Checking whether the visitor was using a mobile device
• Redirecting only mobile users to spam sites
• Injecting hidden scripts from external domains
• Skipping admin, CLI, and API requests to avoid being noticed

Both sites had the exact same payload injected at the top of wp-config.php. The really frustrating part was that every time I cleaned the files, the infection came back within a few hours.

While investigating, I found:

• Backdoor administrator accounts using the sys_ naming pattern and a [email protected] emails
• Backdoor SSH authorized_keys with immutable flags which means the attacker locked the files to prevent removal and the attacker had root-level access to the server at some point, not just WordPress access.

I also found several fake plugins which plugins:

• Copied themselves to wp-content/mu-plugins/ as 01-mu-*.php files (auto-loading, undeletable from dashboard)
• Re-injected wp-config.php on every page load
• Auto-created hidden sys_ admin accounts
• Exfiltrated credentials to a remote server
• Were installed as far months back

Every time I cleaned the site, these plugins would simply put everything back.
After decoding more of the payload, I found a malicious script injection, ak.akam60800.net, a fake domain designed to look like Akamai CDN injecting a script into every frontend page visit to redirect or infect visitors.

After investigation and checking for malicious systemd services, two things stand out:

• defunct.service — described as "D-Bus System Connection Bus", which was a lie. The real D-Bus service is called dbus.service. Which means it was a malicious service masquerading as D-Bus.
• rc-local.service — runs /etc/rc.local on boot, a classic persistence point.

Further investigation revealed that defunct.service was the malware's persistence engine, running a hidden binary at /lib/systemd/system/defunct.dat continuously, restarting every 5 minutes. This is what is reinjecting wp-config.php.

Checking the full service file and the dat file revealed the smoking gun:

• /usr/bin/defunct — the malware binary, disguised as [raid5wq] (a fake kernel thread name)
• /lib/systemd/system/defunct.dat — its config/key file

Checking the dat file and what the binary showed that it is a compiled ELF binary, a sophisticated piece of malware, a cryptominer or botnet agent disguised as a kernel process [raid5wq], and it was actively maintained by the attacker.

Root cause:
A malicious systemd service called defunct.service was running a hidden ELF binary (/usr/bin/defunct) disguised as a kernel thread [raid5wq]. It was continuously injecting a fake Akamai script (ak.akam60800.net) into both wp-config.php files to redirect/infect site visitors, and restarting every 5 minutes.

In summary when malware keep coming up, bear in mind that all problems may not necessarily have something to do with wordpress. A clean wpconfig.php file will not be useful if another component keeps reseting it.

 

[simuqui]

I figured I'd share this in case it helps someone else. I spent days trying to figure this out because I couldn't find much useful information online, and none of the security or malware removal plugins I tried actually solved the problem.​

Overview​

A sophisticated mobile-specific WordPress redirection malware that redirected visitors to spam sites. The malicious code specifically checked the User-Agent string to detect mobile browsers, then redirected only those visitors to avoid detection by administrators, who usually check sites from desktop devices. At first, I thought it was just a typical WordPress infection, but it turned out to be much worse.

How the Infection Worked​

While digging through the files, I found malicious code injected into wp-config.php. It contained Base64-encoded payloads using eval(base64_decode(...)).

After decoding it, I found that it was:

• Checking whether the visitor was using a mobile device
• Redirecting only mobile users to spam sites
• Injecting hidden scripts from external domains
• Skipping admin, CLI, and API requests to avoid being noticed

Both sites had the exact same payload injected at the top of wp-config.php. The really frustrating part was that every time I cleaned the files, the infection came back within a few hours.

While investigating, I found:

• Backdoor administrator accounts using the sys_ naming pattern and a [email protected] emails
• Backdoor SSH authorized_keys with immutable flags which means the attacker locked the files to prevent removal and the attacker had root-level access to the server at some point, not just WordPress access.

I also found several fake plugins which plugins:

• Copied themselves to wp-content/mu-plugins/ as 01-mu-*.php files (auto-loading, undeletable from dashboard)
• Re-injected wp-config.php on every page load
• Auto-created hidden sys_ admin accounts
• Exfiltrated credentials to a remote server
• Were installed as far months back

Every time I cleaned the site, these plugins would simply put everything back.
After decoding more of the payload, I found a malicious script injection, ak.akam60800.net, a fake domain designed to look like Akamai CDN injecting a script into every frontend page visit to redirect or infect visitors.

After investigation and checking for malicious systemd services, two things stand out:

• defunct.service — described as "D-Bus System Connection Bus", which was a lie. The real D-Bus service is called dbus.service. Which means it was a malicious service masquerading as D-Bus.
• rc-local.service — runs /etc/rc.local on boot, a classic persistence point.

Further investigation revealed that defunct.service was the malware's persistence engine, running a hidden binary at /lib/systemd/system/defunct.dat continuously, restarting every 5 minutes. This is what is reinjecting wp-config.php.

Checking the full service file and the dat file revealed the smoking gun:

• /usr/bin/defunct — the malware binary, disguised as [raid5wq] (a fake kernel thread name)
• /lib/systemd/system/defunct.dat — its config/key file

Checking the dat file and what the binary showed that it is a compiled ELF binary, a sophisticated piece of malware, a cryptominer or botnet agent disguised as a kernel process [raid5wq], and it was actively maintained by the attacker.

Root cause:
A malicious systemd service called defunct.service was running a hidden ELF binary (/usr/bin/defunct) disguised as a kernel thread [raid5wq]. It was continuously injecting a fake Akamai script (ak.akam60800.net) into both wp-config.php files to redirect/infect site visitors, and restarting every 5 minutes.

these attack on wp config show that the attacks are persistent from the server side through method such as systemd and a cronjob. At this point just cleaning the plugin will not be enough.

 

[hbar19]

ohh i am glad you have figure it out.
I want to share my input.
Ever your wordpress site becomes infected, get a copy of database backup,media files, wp- content folder.
It covers pretty much everthing. they you can take a clean install and check things one by one which is getting infected and by enabling what thing is not working

 

[RankPilot860]

The defunct.service masquerading as D-Bus is a classic move, seen that exact trick a couple times now where they pick a name thats close enough that a sysadmin skimming systemctl wont look twice. The OpenLiteSpeed cachedata bit is the part most people would miss honestly. You can clean every php file on the box and still serve poison because LSWS already baked the rendered page into its cache.

One thing i'd add for anyone reading this later... after you flush cachedata and kill the binary, check your crontab AND the per user crontabs, not just root. Had a situation where the systemd unit was gone but a www-data cron entry was quietly pulling the payload back every 30 min. chattr +i on authorized_keys is also worth checking like you mentioned, lsattr on the whole .ssh dir saved me there.

Did you ever figure out the initial entry point? curious if it was a vuln plugin or leaked ssh creds, because if you rebuild fresh and the same hole is open you're just gonna be back here in a month.

 

[Rufai]

Did you ever figure out the initial entry point? curious if it was a vuln plugin or leaked ssh creds, because if you rebuild fresh and the same hole is open you're just gonna be back here in a month.

Haven't figures it out yet but I suspect it was a plugin vuln as many of my plugins were outdated.