The WordPress Hack That Stole 90% of an Affiliate Marketer’s Paid Traffic

A client called me a few months ago with a problem that didn't make much sense. Their paid traffic had been dropping steadily for more than a month.

Not a sudden collapse. Nothing dramatic. Just a slow, consistent decline.

By the time they reached out, the traffic they were seeing was less than 10% of what they had been getting two months earlier. The strange part was that they were still paying for the clicks. The ad platform showed traffic going out.

The money was being spent. But the visitors weren't showing up where they were supposed to. Naturally, the first thing everyone looked at was the website.

It seemed fine.

Pages loaded quickly. The site was responsive. Product pages worked. Orders went through. There were no strange popups, no obvious redirects, no spam pages, and no visible signs that the WordPress installation had been compromised.

Several people had already looked at the site and came to the same conclusion: Everything seemed to be working correctly. For most visitors, it was.

The problem only affected paid traffic

Eventually, we ran an AI-assisted malware scan across the WordPress installation. That's when the whole thing finally made sense.

Buried inside the site was a small piece of malicious code that didn't behave like the malware most people imagine.

It wasn't redirecting every visitor.

It wasn't replacing the homepage.

It wasn't injecting obvious spam.

Instead, it looked at the incoming request and checked for parameters that identified traffic coming from the client's advertising campaigns.

In other words, the malware knew the difference between someone casually visiting the website and someone the client had just paid to acquire.

If I typed the domain into my browser, I saw the normal site.

If the client opened the homepage, they saw the normal site.

If a developer checked the site, everything looked normal.

But if the request contained the tracking parameters associated with a paid advertisement, the malware activated. That was the key to the entire attack.

The attacker wasn't stealing every click

The malware was also careful not to redirect all of the paid traffic.

It used the visitor's IP address as part of a simple calculation and then selected only a percentage of qualifying visitors to redirect.

Conceptually, it worked something like this:

• A visitor clicks an ad.
• The request arrives at the WordPress site.
• The malware sees the advertising parameters.
• It performs a modulo-style calculation using the visitor's IP address.
• Based on the result, that visitor either continues to the legitimate website or gets redirected somewhere else.

That "somewhere else" was the clever part. The attacker had created a cloned version of the client's website.

It looked the same. The products were the same. The sales flow was the same. From the customer's perspective, nothing had really changed.

There was only one important difference: The affiliate ID was different.

The client was paying to generate the click. The attacker was collecting the commission.

They slowly turned up the percentage

The attack also explained why the traffic loss had been so gradual. The attacker apparently didn't start by stealing 90% of the traffic. That would have been obvious.

Instead, the percentage was increased over time. A small amount of traffic disappeared first. Then a little more.

Then more again.

By the time we found the compromise, roughly 90% of the client's paid traffic was being siphoned away. That slow ramp-up made the problem look much more like an advertising or conversion issue than a security incident.

• Maybe the campaign wasn't performing as well.
• Maybe the audience had changed.
• Maybe competitors were bidding more aggressively.
• Maybe the landing page needed work.

Those are all much more obvious explanations than: "Someone hacked your WordPress site, identified only the visitors you're paying for, and selectively redirected them to a clone so they could steal your affiliate commissions."

But that was exactly what was happening.

Why nobody noticed

This is what made the attack so effective:

• The website itself wasn't broken.

The attacker wanted the website to keep working. They wanted the client to keep buying ads. They wanted the campaigns to continue running. They wanted the client to keep doing all the expensive work of finding qualified customers.

The malware simply inserted the attacker into the transaction.

And because the redirect only occurred when specific advertising parameters were present, manually checking the website wasn't enough. You could spend hours clicking around the WordPress installation and never trigger the malicious behavior.

The code didn't look obviously malicious

Another interesting part of the compromise was how ordinary many of the individual pieces looked.

Reading request parameters is normal. Checking an IP address is normal. Performing a modulo calculation is normal. Redirecting a visitor is normal. Affiliate websites do all of those things legitimately.

It was only when the scanner looked at how those actions worked together that the real behavior became apparent.

• Paid visitor detected.
• Traffic percentage calculated.
• Selected visitor redirected.
• Cloned site displayed.
• Different affiliate credited.

Cleaning it up was the easy part

Malware cleanup was actually straightforward. The malicious code was removed, the site was checked for additional modifications, and the legitimate traffic flow was restored.

The more important question was how to keep it from happening again.

The client switched to Runtime Application Self-Protection, or RASP, security solution that prevents unauthorized modifications to protected files.

If compromised code attempts to write or modify a protected PHP file, the operation itself can be blocked.

Since installing the additional runtime protection, the client hasn't had the problem again.

The biggest lesson

Most people imagine a hacked WordPress site as something obvious.

• The homepage gets defaced.
• Spam pages appear.
• The browser throws a malware warning.
• The site stops working.

But that's often the least useful outcome for an attacker. If the goal is making money, the attacker may want the website to look perfectly healthy.

In this case, the client kept paying for advertisements:

• Customers kept clicking them.
• The website kept working.
• Orders kept processing.
• The only thing that changed was who got paid.

And for more than a month, that tiny difference was enough to hide the compromise in plain sight.

Sometimes the most dangerous website attack isn't the one that takes your site offline.

It's the one that leaves everything running exactly as expected while quietly inserting someone else into your revenue stream.