How I Recovered from a Sophisticated WordPress Mobile Redirection Malware

Rufai · Jun 21, 2026

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 · Jun 21, 2026

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

Campaigns By Mike · Jun 21, 2026

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 · Jun 21, 2026

Panther28 said:
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.

Campaigns By Mike said:
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.

Campaigns By Mike said:
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 · Jun 21, 2026

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

Rufai · Jun 21, 2026

GhostlyGardener said:
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 · Jun 22, 2026

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 · Jun 22, 2026

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 · Jun 22, 2026

Patrikan said:
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 · Jun 22, 2026

Rufai said:
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 · Jun 23, 2026

Rufai said:
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 · Jun 24, 2026

Rufai said:
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 · Jun 24, 2026

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 · Jun 24, 2026

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 · Jun 24, 2026

RankPilot860 said:
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.

How I Recovered from a Sophisticated WordPress Mobile Redirection Malware

Supreme Member

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​

How the Infection Worked​

Elite Member

Junior Member

Supreme Member

Newbie

Supreme Member

Elite Member

Newbie

Supreme Member

Newbie

BANNED

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​

How the Infection Worked​

Newbie

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​

How the Infection Worked​

Regular Member

BANNED

Supreme Member

Main Menu

Marketplace

Making Money

BlackHat World

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

How the Infection Worked

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

How the Infection Worked

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

How the Infection Worked