SavvyWolf MANAGER PHP Web-Shell Variant

Summary

This entry documents a PHP artifact whose rendered interface identifies itself as SavvyWolf - MANAGER. A retained screenshot shows that interface listing directories and files under an anonymized WordPress wp-content path. The supplied PHP source also searches upward for WordPress directory markers and attempts to copy its current file to three WordPress-related locations.

The evidence supports a SavvyWolf web-shell classification and a self-copy attempt. It does not establish root-level operating-system access, the original deployment method, or every capability that may have existed in a longer sample.

Investigation context

The artifact was observed during one anonymized WordPress client investigation. The privacy-safe screenshot preserves the manager branding, directory context, and file list while irreversibly obscuring the hosting account path.

A broader hidden backdoor investigation in wp-content explains how unknown PHP files should be triaged. This page is narrower: it records the SavvyWolf interface marker, its defined filenames, and the copy flow present in the supplied code.

Observed SavvyWolf MANAGER interface

The screenshot displays the heading SavvyWolf - MANAGER, an anonymized directory ending in /wp-content, common WordPress content folders, and files including edit-wolf.php. This is direct visual evidence of the branded interface and its filesystem context. It does not show a file being edited, uploaded, deleted, or executed.

Confirmed findings

• The rendered page used the SavvyWolf - MANAGER label.
• The interface listed a WordPress wp-content directory and an edit-wolf.php file.
• The supplied source searches parent paths for wp-content, wp-admin, and wp-includes/widgets directories.
• It defines three target names: admin-wolf.php, edit-wolf.php, and class-wp-wolf-widget.php.
• It calls PHP’s copy() function for each available target directory.

Technical analysis of the self-copy logic

The source first tries to derive a likely site root from the current directory. If the current path contains public_html, it uses that boundary. Otherwise, it walks toward parent directories until it finds the three expected WordPress paths.

After locating a candidate root, the code checks each target directory and attempts to copy the current PHP file to a wolf-themed filename. The visible source records successful copy targets in an array, but the retained evidence does not independently confirm that all three writes succeeded in the investigated environment.

Redacted defensive excerpt

candidate_root = locate_parent_with_wordpress_directories()

copy_targets = [
    "wp-admin/[wolf-themed filename]",
    "wp-content/[wolf-themed filename]",
    "wp-includes/widgets/[wolf-themed filename]"
]

for each existing target directory:
    attempt to copy the current file to the defined target

The public excerpt omits the operational interface and executable PHP implementation. It retains only the directory markers and copy pattern needed for defensive searches.

Analyst assessment

The code’s copy attempts are consistent with redundancy or persistence: removing one copy would not necessarily remove another successfully written copy. That purpose is an analyst assessment based on the source structure. The repository evidence does not show a later request to each target or prove that every copy remained executable.

Indicators of compromise

Higher-confidence indicators

• Interface marker: SavvyWolf - MANAGER
• edit-wolf.php
• admin-wolf.php
• class-wp-wolf-widget.php
• The three-file combination across wp-content, wp-admin, and wp-includes/widgets

Contextual indicators

• A PHP file under wp-content
• References to public_html
• Directory walking with dirname()
• Use of copy()

These generic paths and functions require the distinctive branding, filenames, or code relationship before they should be treated as meaningful evidence.

What this evidence does not establish

• The screenshot does not show which manager actions were available or used.
• The supplied excerpt does not prove root or administrator privileges on the server.
• It does not show that all three copy operations succeeded.
• The original deployment method was not confirmed.
• No vulnerable plugin, theme, or affected version was identified.
• No campaign attribution, prevalence, or client outcome is claimed.

Artifact-specific remediation

Preserve the files, timestamps, and relevant access logs before removal when investigation history matters. Identify every copy by comparing content and verified hashes from the retained private evidence—not by deleting every file containing “wolf.” Remove confirmed malicious copies and replace affected WordPress core or third-party directories from trusted sources.

Review access logs for requests to the confirmed filenames, inspect other writable paths and persistence mechanisms, rotate credentials within the confirmed exposure scope, and verify administrator accounts. The Tiny File Manager backdoor case study provides a separate full recovery narrative; it is not evidence that SavvyWolf entered the same way.

Recurrence verification

• Search again for the three distinctive filenames after cleanup.
• Compare wp-admin and wp-includes with clean WordPress packages.
• Monitor file creation in the three code-defined target directories.
• Review requests to removed filenames and investigate any continuing source.
• Confirm that no copy reappears after scheduled tasks, deployments, or administrator logins.

Related malware research

• HTTP-header-gated PHP loader
• wp-config.php XOR temporary-file loader
• functions.php credential logger using a fake PNG filename

Methodology and privacy note

This entry uses one privacy-reviewed screenshot and a supplied PHP source excerpt retained from an anonymized investigation. Client-specific filesystem values are irreversibly redacted in the public image. The complete shell is not reproduced; the public code section is an inert defensive summary of the observed directory and copy logic.