Skip to content
Threat reports

Quarterly threat intelligence.

Long-form research from the RedSecLabs team on what we are seeing across compromised WordPress sites, trends, families, and the techniques attackers are reaching for now.

What we publish

Findings from real cleanups, not repackaged vendor statistics

Threat reporting in this market is largely aggregate telemetry: counts of blocked requests, top attacked plugins, month-on-month percentages. Those numbers are real and they are mostly useless to a site owner, because knowing that attacks rose eleven per cent tells you nothing about what to do on Tuesday.

What we write up instead are mechanisms. How a particular payload achieved persistence, why it survived a filesystem cleanup, which table it hid in, what the scanner that missed it was looking for, and what would have caught it. That is the material that changes how someone configures a site.

Where a technique is novel enough that publishing it would help attackers more than defenders, we describe the class rather than the recipe. That judgement is made case by case and we would rather be criticised for withholding detail than for publishing a working method.

Recurring patterns

The three that account for most reinfections

Database persistence is the largest single cause of a site being cleaned and then compromised again within days. A serialised payload in wp_options, a fake transient that reinstates itself after deletion, or a hook that rewrites files on the next page load, the filesystem cleanup was thorough and irrelevant.

Credential reuse is the second. The compromise did not exploit a vulnerability at all; someone logged in with a password that appeared in a breach corpus years ago. No amount of scanning prevents that, which is why two-factor authentication matters more than any detection feature.

The third is the unpatched window on a disclosed plugin vulnerability. Exploitation begins within hours of public disclosure, patches take days to ship and weeks to be applied, and a large share of compromises land in exactly that gap.

How to use this

Reading threat research without changing everything

The failure mode of security reading is reactive configuration: an article describes an attack, and a site owner enables six new controls without knowing whether any of them address their actual exposure.

A better test is whether a described technique would work against your site as configured, and that is a specific question with a specific answer. If the payload persisted in wp_options, run a database scan. If it arrived through credential reuse, check whether two-factor is on for every administrator. If it used an unpatched plugin, look at how quickly you actually apply updates.

Most sites need three or four controls done consistently rather than fifteen done once. Research is most useful when it tells you which three.

FAQ

Common questions

Why not publish attack volume statistics?

Because they do not help. Knowing that attacks rose eleven per cent tells a site owner nothing actionable. Mechanisms (how a payload persisted, what missed it, what would have caught it) change how someone configures a site.

Do you publish full exploitation detail?

Not where publishing would help attackers more than defenders. In those cases we describe the class of technique rather than a working method. That judgement is made case by case.

What causes most reinfections?

Database persistence, by a wide margin. A payload in wp_options or a fake transient survives a thorough filesystem cleanup, which is why the database scanner is in the free plugin.

What is the most underrated control?

Two-factor authentication. A large share of compromises involve no vulnerability at all, someone logged in with a password that appeared in a breach corpus years ago, and no amount of scanning prevents that.

How should I act on threat research?

Ask whether the described technique would work against your site as configured. That is a specific question with a specific answer, and it beats enabling six new controls reactively.