system-control Plugin Restored from wp-content/.sc-backup

Summary

This WordPress malware research entry documents self-restoring fake plugin persistence evidence observed during one anonymized client investigation. The narrow topic is system-control Plugin Restored from wp-content/.sc-backup: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.

The source and destination evidence establish self-restoring plugin persistence. Casino and fake-CAPTCHA screenshots occurred in the same investigation, but this page does not claim the loader alone produced those symptoms.

Investigation context

Anonymized multi-artifact investigation with nine screenshots and retained sc-loader.php, system-control.php, MU-plugin, and theme samples. 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

A hidden system-control backup existed at the loader’s source path.

sc-loader.php and additional access artifacts existed under mu-plugins.

The system-control destination plugin directory existed.

Confirmed findings

• sc-loader.php defines wp-content/plugins/system-control as the destination.
• It defines wp-content/.sc-backup/system-control as the backup source.
• The code copies from the backup when the destination is absent and calls activate_plugin.
• The screenshots show the source, destination, and sc-loader.php under mu-plugins.

Technical analysis

How sc-loader.php restores the plugin

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

$pluginDir = WP_PLUGIN_DIR . '/system-control';
$backupDir = WP_CONTENT_DIR . '/.sc-backup/system-control';
if (destination_missing() && is_dir($backupDir)) {
    copy_directory($backupDir, $pluginDir);
    activate_plugin('system-control/system-control.php');
}
// deletion resistance and helper implementation shortened

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 source and destination evidence establish self-restoring plugin persistence. Casino and fake-CAPTCHA screenshots occurred in the same investigation, but this page does not claim the loader alone produced those symptoms.

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

• wp-content/.sc-backup/system-control
• sc-loader.php
• system-control/system-control.php
• Copy-then-activate persistence flow

Contextual indicators

• plugins_loaded
• activate_plugin()
• MU plugin
• Generated theme directory names

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 initial compromise method was not confirmed.
• The relationship between each generated theme directory and system-control was not individually established.
• Visitor-facing spam screenshots do not identify which component rendered the content.
• Operational request triggers, credentials, secrets, and complete backdoor code are withheld.

Artifact-specific remediation

• Preserve the source, destination, loader, and related MU-plugin files.
• Remove sc-loader.php before deleting both system-control copies so the loader cannot restore them.
• Review every MU plugin, administrator account, cron job, and generated directory in the same incident.
• Replace compromised themes and plugins with trusted copies and rotate credentials.

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

• Confirm both system-control paths remain absent.
• Monitor wp-content for recreation of .sc-backup and sc-loader.php.
• Verify the plugin list and filesystem remain consistent after requests and scheduled tasks.

Related malware research

Browse the WordPress malware research hub.

• media-patcher-lab.php Found in WordPress mu-plugins
• StateMesh MU-Plugin Self-Copy and Plugin-List Concealment
• wp-user-query.php MU-Plugin Concealing a Stored User ID

Related guides and case studies

• Why WordPress malware keeps returning
• Hidden WordPress backdoor investigation
• Regenerating system-control malware case study

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.