Skip to content
MP MD Pabel WordPress security

WordPress Malware Research Entry

TokensDeGuards Payload Verification and eval in index.php

Found a TokensDeGuards identifier or suspicious PHP in a WordPress index.php? Review the structural evidence without executing the sample.

Reviewed: July 22, 2026
Artifact class Authenticated compressed PHP loader
Evidence confidence High
Risk assessment Critical

Start with the problem you are seeing

Could this match the problem on your WordPress site?

This entry is for owners whose scanner or developer finds a TokensDeGuards-style index.php artifact. The file’s identifier and structure support further investigation, but no request log or execution trace was retained.

Observed in this investigation

  • The supplied index.php artifact contained the distinctive TokensDeGuards identifier and nonstandard PHP structure.

Possible warning signs

  • A file scan may be the only sign while normal pages continue to load.
  • The artifact may sit in an unexpected directory whose index.php would normally be minimal or inert.

These signs are investigation leads, not proof of this artifact by themselves.

Questions this research can help answer

  • What is TokensDeGuards in a WordPress index.php file?
  • Does a suspicious index.php prove that malware executed?

Evidence boundary: The artifact is confirmed; execution, access, and any resulting site change are not established.

Seeing one of these signs on your site?

I can investigate the files, database records, users, and server evidence, explain what is confirmed, and help plan a safe cleanup.

Ask me to investigate your site See how my malware cleanup works

Research focus: Forensic review of an index.php class that checked a keyed message, inflated its payload, and passed the result to eval.

Summary

This WordPress malware research entry documents authenticated compressed php loader evidence observed during one anonymized client investigation. The narrow topic is TokensDeGuards Payload Verification and eval in index.php: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.

The keyed check suggests the loader only evaluates payloads with a matching message tag. The evidence does not show where the message originated or the behavior of the inflated body.

Investigation context

Anonymized investigation with one code screenshot and retained index.php excerpt. The report date is retained from the original investigation notes. Broader cleanup guidance remains in the WordPress malware removal guide; this entry is limited to what the supplied code and screenshots support.

Observed artifact

index.php verified, inflated, and evaluated an embedded message.

Cropped PHP editor view showing HMAC verification, gzinflate, and eval in index.php
The privacy-safe crop shows the payload-verification branch, gzinflate call, and eval without the client domain visible in the original editor header.

Confirmed findings

  • The visible code recalculates a keyed hash over a version and message.
  • It rejects a tag that fails hash_equals.
  • It calls gzinflate on the payload and evaluates the resulting value.
  • The identifier PayloadCodecsException appears in error handling.

Technical analysis

How verification precedes payload inflation

The following code keeps the identifiers and control flow needed for defensive verification while removing secrets, complete payloads, and operational request instructions.

Redacted defensive excerpt

$expected = substr(hash_hmac(/* algorithm and key redacted */), 0, strlen($tag));
if (!hash_equals($tag, $expected)) throw new Exception('verification failed');
$decoded = gzinflate($payload);
eval($decoded); // embedded message omitted

This excerpt is intentionally incomplete. It should be used for code search, baseline comparison, and incident review—not copied into a live site.

Analyst assessment

The keyed check suggests the loader only evaluates payloads with a matching message tag. The evidence does not show where the message originated or the behavior of the inflated body.

The severity reflects the capability visible in this artifact and its position in the investigated WordPress environment. It is not a claim about campaign prevalence, a particular vulnerability, or an outcome that the retained evidence does not show.

Indicators of compromise

Higher-confidence indicators

  • TokensDeGuards
  • PayloadCodecsException
  • Keyed tag verification followed by gzinflate and eval

Contextual indicators

  • index.php
  • hash_hmac()
  • hash_equals()
  • eval()

Contextual indicators are not proof of infection by themselves. Confirm them through trusted-file comparison, neighboring code, database provenance, request logs, or the distinctive combinations listed above.

What this evidence does not establish

  • The inflated payload is not published.
  • The screenshot does not prove the eval branch ran.
  • The initial compromise method, message source, and visitor outcome were not established.
  • The original screenshot is excluded because it displayed a client domain.

Artifact-specific remediation

  • Preserve the full index.php and message material privately.
  • Replace index.php with the clean WordPress front controller.
  • Search for TokensDeGuards, PayloadCodecsException, and the verification-to-eval sequence.
  • Review adjacent files and persistence mechanisms.

For a complete response sequence, use the broader malware-removal guide or the WordPress malware-removal service when hands-on incident response is appropriate.

Recurrence verification

  • Verify index.php remains identical to the trusted copy.
  • Repeat the class-name and exception-name search.
  • Monitor root files for recreation after traffic and cron tasks.

Browse the WordPress malware research hub.

Methodology and privacy note

This analysis is based on retained code, screenshots, paths, and notes from an anonymized WordPress client investigation. Confirmed findings are limited to visible or supplied evidence; professional interpretation is labeled as analyst assessment. Screenshots were reviewed for client identifiers, account paths, usernames, email addresses, credentials, tokens, database details, and unrelated records. Sensitive or operational material remains outside the public page, and every public code block is a redacted defensive excerpt.