Is your WordPress site running this?

post-sitemap.xml

The list of posts your SEO plugin hands to Google. Yoast names it this; All in One SEO and others use sitemap.xml with a posts sub-sitemap. Count the <url> entries.

wp-json/wp/v2/posts?per_page=100

WordPress's own REST API listing published posts. Count the entries (each starts with "id":). If you have more than 100 posts, add &page=2.

wp-admin

Posts, All Posts, the "Published" count.

All three come from the same table. They should agree. This malware filters the REST API and the admin list but not the SEO plugin's sitemap, so the sitemap is the one that tells the truth.

SELECT DISTINCT post_author FROM wp_posts

List every author ID that appears on any post, once each.

WHERE post_author NOT IN (SELECT ID FROM wp_users)

Keep only the ones that do not match a real user account.

Every legitimate post is owned by a user. The kit assigns its posts to made-up author numbers, because "author 7023" is cheaper to hide than a real account and never shows up in the Users screen. An empty result is clean.

SELECT COUNT(*) FROM wp_options

Count rows in the settings table.

WHERE option_name LIKE 'home_links_custom_%'

Only rows whose name starts with home_links_custom_. The % is a wildcard for "anything after this".

The kit stores its hundred hidden-text variants as home_links_custom_0 to _99. No legitimate plugin uses that name. The operators randomise almost everything else per site, but not this.

The kit registers its own feed named xmlsitemapNN and a rewrite rule mapping sitemapNN.xml to it, where NN is a campaign number (23 on the infected site). It lists only the campaign's posts, so Google finds them even though the real sitemap plugin does not know about them. A 404 on both is clean. A valid XML sitemap that your SEO plugin did not make is the kit.

curl -sL

Fetch a page. -s keeps it quiet, -L follows redirects (most sites bounce from the bare domain to www, and without -L you would save the redirect instead of the page).

-A "Mozilla/5.0 (compatible; Googlebot/2.1; ...)"

Send Google's crawler user agent so the site thinks Google is asking.

> as-google.html

Save the response to a file.

diff as-google.html as-browser.html

Show every line that differs between the two saved pages. No output means identical.

Then search both files for opacity:0.003, left:-5000px, casino, pokies and slot. The kit rotates between ten hiding techniques keyed to your hostname, so grep for the words rather than the CSS. Note that this kit cloaks by IP address rather than user agent, so from your own machine both fetches get the version with the payload attached. That is fine. You are reading the HTML, not running it, and the point is to see the hidden block at all.

FROM wp_usermeta m JOIN wp_users u ON u.ID = m.user_id

Pair each row of per-user metadata with the user it belongs to, so you get a username instead of a number.

WHERE m.meta_key = 'session_tokens'

Only the row that holds that user's active login sessions.

SELECT u.user_login, m.meta_value

Show the username and the raw session data.

The value is a serialised PHP array with one entry per live session, each carrying the IP address, user agent and login time. A normal account holds one or two. The compromised account on the infected site held 62, one per attacker IP. That tells you which account the operator is using and gives you the addresses to look for in the logs.

grep '"POST /wp-login' access.log

Keep only lines where someone submitted the login form.

| grep '" 302 '

Of those, keep the ones the server answered with a redirect. WordPress redirects on a successful login and re-shows the form (200) on a failed one, so 302 means the password was right.

| awk '{print $1}'

Take just the first column, the client IP.

| sort | uniq -c | sort -rn

Count how many times each IP appears and list the busiest first.

grep -oE '"(GET|POST) /wp-[^ ?"]+\.php[^"]*" [0-9]{3}'

Pull out just the request path and status code for every request to a PHP file under a wp- directory. -o prints only the matching part, -E enables the pattern syntax.

In the second list, anything ending in 404 is the internet guessing at files that do not exist, which every site on earth receives constantly. Anything you do not recognise ending in 200 is a file that exists on your server and is being used.

Yours will be a different hash. The two identical comments mark the start and end of the injected block so the operator's tooling can find and update it later. Between them is around 400 lines of clean, readable PHP with no obfuscation. Every function is named after a real WordPress function with a word bolted on: get_sidebar_double, is_singular_cookie, wp_footer_branch, get_template_part_compiler. It reads like theme code, which is the point.

$_SERVER['HTTP_HOST']

Your site's hostname, as sent by the visitor's browser.

md5(sha1(...))

Hash it twice, producing a 32-character string that is different for every hostname.

get_option(...)

Read a WordPress setting with that string as its name.

So the kit's configuration is stored under a name that is never written in the code and differs on every infected site. A list of known-bad option names finds nothing. This line is how it loads its settings, and it is the single most reliable signature of this kit in a file.

FROM wp_posts WHERE post_type IN ('wpcode', 'code_snippets', 'snippet')

Snippet plugins store each snippet as a row in the posts table with a special type. This pulls those rows and nothing else.

SELECT ID, post_title, post_date, post_status, LENGTH(post_content)

Show the ID, its title, when it was created, whether it is active (publish), and how long the code is.

Then read the actual code of every one. On the infected site the malicious snippet was titled "Completely Disable Comments", lifted from the plugin's own example library, and its code did nothing of the sort. It hooked template_include at maximum priority, scanned every request for gambling keywords, turned 404s into 200s, and rewrote noindex to index. It is not a file. Core reinstalls and file scanners cannot see it.

WHERE autoload = 'yes'

Only settings WordPress loads on every single page view.

ORDER BY 2 DESC LIMIT 25

Sort by the second column, the size, largest first, and show the top 25.

The kit needs its configuration on every request, so it marks it autoload. In a normal site every name in the top 25 is recognisable: a theme, a plugin, WordPress itself. An option named as 32 hex characters, a few kilobytes in size, is the kit's configuration. You will also find wp_custom_range (cached Google IP ranges) and possibly wp_custom_filters.

grep 'wp_version =' site/wp-includes/version.php

Find out which WordPress version the site runs. Use that number in the next line.

curl -sSL -o wp.zip https://wordpress.org/wordpress-7.0.4.zip && unzip -q wp.zip -d ref

Download the official release of exactly that version and unpack it into a folder called ref.

find . -type f | sort

List every file under a folder, alphabetically.

comm -23 <(list A) <(list B)

Compare two sorted lists and print only the lines that are in A but not in B. So: every file on your site that is not in the official release. The <( ) wrapper feeds a command's output in as if it were a file.

find ... -exec md5sum {} +

Compute a fingerprint of every file's contents.

join ... | awk '$2!=$3 {print $1}'

Line the two fingerprint lists up by filename and print any file whose fingerprint on your site differs from the official one. That is a modified core file.

Two lists come out: files that should not exist, and files that have been altered. This has no false negatives and needs no signatures. On the infected site it found sixteen files in ten minutes, including four that no pattern in this guide would have caught. Expect the "should not exist" list to include a few harmless things from your host, so check each one rather than deleting the list blindly.

find wp-content/uploads -type f

Walk every file under the uploads folder.

\( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)

Keep only those with a PHP-executable extension. The -o means "or"; the escaped brackets group the three tests.

Uploads holds media. Every hit is either a plugin datastore that announces itself (sucuri-settings.php opens with <?php exit(0); ?>, and Smush and similar leave an index.php containing only a comment) or malware. Also look for a year folder with no month folders inside it. WordPress never creates one of those.

find . -name "*.php" -size -1k -exec grep -l "include_once __DIR__" {} \;

Every PHP file under 1 KB that contains the phrase include_once __DIR__. The split web shell is reassembled by a 446-byte loader that does nothing but include eleven sibling files. Nothing legitimate is that small and does that.

find . -type f -name "*.php" \( -size 403c -o -size 1117c \)

PHP files that are exactly 403 or 1,117 bytes. c means bytes. Those are the two remote-loader variants, and their size never changes between deployments.

... -size 446c -o -size 11512c ...

Same idea for the other fixed-size pieces of the shell suite.

grep -rlE "eval\((curl_exec|file_get_contents)" --include="*.php" .

Search every PHP file (-r recursive, -l list filenames only) for code that fetches something over the network and executes it directly. That construct has no legitimate use in a WordPress site.

find wp-includes wp-admin -name "class-*-*.php" | while read f; do [ -f "ref/wordpress/$f" ] || echo "$f"; done

For every file whose name looks like a core class file, check whether the official release has a file at that same path. Print the ones it does not. This catches names like class-smtp-integer.php sitting beside the real class-smtp.php. It needs the ref folder from rule zero.

Filenames are worthless as an indicator. The operator randomises them per deployment. Sizes are not, because the payloads are identical every time.

ls wp-content/mu-plugins/

List the "must-use" plugins folder. Anything in here runs on every request and does not appear in the normal Plugins screen. Managed hosts put their own files here, so expect a few. Read any you do not recognise.

ls wp-content/db.php ...

Check for the three "drop-in" files. If present, WordPress loads them before anything else, including before security plugins. On most sites none exist, and "No such file" for all three is the good answer. If one exists and you did not install a caching plugin that uses it, read it.

Pulls the list of scheduled tasks. WordPress runs these on a timer. Malware commonly registers one to re-plant itself after a cleanup, which is the most common reason a cleaned site comes back infected a day later. The value is a serialised array; search it for hook names you do not recognise. Legitimate entries are named after WordPress and your plugins (wp_update_plugins, wpseo_..., woocommerce_...).

UA="..."

Store the Googlebot user agent in a variable so the next line stays readable.

while read p; do ... done < removed-paths.txt

Run the middle line once for each line of the file, with $p set to that path.

printf '%s ' "$p"

Print the path, without a newline, so the result lands beside it.

curl -sL -A "$UA" -o /dev/null -w '%{http_code} %{size_download}\n' "https://yoursite.com/$p"

Fetch the path as Googlebot, throw the body away (-o /dev/null), and print only the status code and the byte count.

Every line should be 404, or 403 on hosts that block PHP under uploads. A 200 with a zero-byte body is a live backdoor waiting for a parameter it has not been given. On the infected site two of those were still there three hours after the delete commands were written, because the commands were never run. Nothing about the response looked wrong. Only the status code knew.