ATTENTION! The deleted malicious software on WordPress sites is being restored in a few seconds!

ATTENTION! The deleted malicious program on WordPress sites is being restored in a few seconds! A newly discovered SC malicious program has the ability to restore deleted malicious files within a few seconds, bypassing normal cleaning procedures against WordPress sites. According to the analysis published by experts on September 30, 2026, this malicious program can restore its main parts by placing them in various locations such as site files, the database, and server memory, and restoring the remaining parts from them. The most dangerous aspect of this situation is that even after site administrators find and delete the malicious file, the infection may not be removed. Instead, other hidden components in the system can recreate the deleted file and continue the malicious program's activities. Experts' investigation revealed how the SC malicious program entered the site and how many websites were affected. However, the identified mechanism shows that it uses several independent ways to remain hidden and be restored within the site for a long time. The main feature of the SC malicious program is its ability to restore itself. Administrators usually look for suspicious PHP files, unknown plugins, or modified theme files when detecting many malicious programs. However, in the SC case, deleting a single file is not enough. Investigators found that the malicious program components are placed in at least eight different locations, arranged in a way that they can restore each other. For example, if a malicious plugin is deleted, another component recreates it. If this component is also deleted, hidden code or a database copy in the theme file can be activated. As a result, the following situation occurs: malicious component → restores another component → which restores another component → the malicious program is fully restored. This means that simply deleting a file is almost useless for eliminating SC. The malicious code can activate even before WordPress starts. The SC malicious program uses the .user.ini file from one of its important parts, and the auto_prepend_file directive in it instructs PHP to load a specific file before executing a normal PHP request. The dangerous aspect of this mechanism is that in some cases, the malicious code can run before WordPress fully starts. That is, the attacker does not just stick to WordPress plugins or themes. This mechanism at the PHP level allows the malicious code to run before WordPress processes incoming requests to the site. Furthermore, PHP can cache this setting for a certain period. Therefore, if an administrator simply deletes the file specified by auto_prepend_file, PHP requests may not work temporarily in some cases. Sucuri recommends paying special attention to the order of operations when cleaning this component. The malicious plugin is hidden in two places. SC also uses another important method. The malicious plugin can exist simultaneously in: wp-content/plugins directory; wp-content/mu-plugins directory. mu-plugins — This is WordPress's Must-Use Plugins mechanism, where plugins are loaded automatically and do not appear in the simple plugin list in the WordPress control panel. They usually cannot be removed from the control panel. This feature creates a convenient opportunity for attackers. In the SC case, the malicious plugin can even be disguised as legitimate software. It has settings pages, shortcodes, and other normal WordPress components, appearing as a real plugin in the initial check. Therefore, checking only the wp-admin -> Plugins section does not indicate that the site is clean. The database is also turned into a hidden repository of the malicious program. Another dangerous aspect of SC is the storage of a full copy of the malicious code in the database. Investigators found large amounts of data in the database under unknown names in the gzip + Base64 format. This data contains a full copy of the malicious program. If the main malicious plugin on the site is deleted, another component can take this copy from the database and recreate it in file format. This means that antivirus or manual cleaning processes limited to checking only WordPress files may not fully detect the infection. A copy can also be stored in server memory. One of the more complex aspects of SC is the use of the System V shared-memory mechanism by the malicious code. In this, the malicious PHP code can be stored in the server's shared memory segment rather than as a file on the disk. As a result, the copy remains in server memory even after the administrator deletes the malicious files and even some entries in the database. This copy is used to return malicious components to the site in the next request. This is one of the important features that distinguishes SC from ordinary website malicious programs. The theme file is also turned into a restoration mechanism. The malicious code can be added to the functions.php file of the active theme. This code is usually added as a hidden block at the end of the existing legal code. If this block detects that the malicious plugin is deleted, it recreates its copy. This shows how important it is to check the dependencies between files when cleaning a WordPress site. The malicious program also hides itself from administrators. SC does not just limit itself to hiding technical components. Investigators found that it can remove itself from the WordPress control panel's plugin list, remain invisible in update checks, and in some cases, create hidden administrator accounts or use existing accounts. Such accounts may not appear in the regular list of users. The malicious program can directly modify user rights in the database and create authentication information for the administrator. Therefore, relying only on the list of users in the control panel is not enough to check the site. The users and their rights in the database must also be checked. Administrator session tokens are also targeted. The SC malicious program can also acquire information related to active administrator sessions along with the site's technical information. This increases the possibility that the attacker can use the administrator's active session. Therefore, after detecting the malicious program, it is important to not only change the WordPress password but also to terminate all active sessions and update the relevant authentication tools. Especially, passwords and keys for the site administrators, hosting panel, FTP/SFTP, SSH, database, API, and other services must also be checked. Blockchain infrastructure is used to deliver commands. One of the strangest aspects of the SC malicious program is its method of connecting to its command and control infrastructure. Investigators found that the malicious program uses approximately 20 public Ethereum RPC gateway addresses and receives instructions via smart contracts. Here, the blockchain itself is not malicious. The problem is that attackers use legally used blockchain infrastructure as their command channel. Therefore, network administrators should not be limited to blocking only one identified IP address or domain. The malicious program can use other gateways. The malicious program can send new code and browser scripts to the site. When remotely controlled, the attacker can give it commands such as installing new PHP code or sending JavaScript to the site. This poses a serious risk, especially for online stores. It can be used to hold payment information entered by the user or interfere with the checkout process. Furthermore, the malicious program can delete security plugins or their directories. This gives the attacker more time to maintain control over the site. Why is repeatedly deleting the malicious file useless? In the SC case, the problem is not in a single file, but in a network of mutually linked persistence mechanisms. For example: .user.ini — starts the loader before PHP requests; - hidden PHP file — calls the next component; db.php — stores a copy of the malicious program; advanced-cache.php — restores the malicious code from other sources; functions.php — recreates it when the plugin is deleted; mu-plugins — loads the malicious code automatically; database — stores a full payload copy; shared memory — keeps a copy outside the disk; cron tasks — serve to reposition malicious components. Therefore, the approach of "I found the file -> I deleted it -> The problem is solved" is not enough in such infections. Main IOCs related to the SC malicious program The following indicators may be considered when checking for SC or similar WordPress infections: | Type | Suspicious Sign | |---|---| | Configuration | Unknown auto_prepend_file directive in .user.ini, php.ini, or .htaccess | | PHP files | Randomly named or hidden PHP files in wp-content | | Drop-in | Unknown code in wp-content/db.php or advanced-cache.php files | | MU-plugin | Unknown PHP files in wp-content/mu-plugins | | Simple plugin | Unknown plugin disguised as a legitimate plugin in wp-content/plugins | | Theme | Unknown code block added to the end of the active functions.php file | | Archives | Randomly named ZIP files in wp-content or uploads | | Database | Large amounts of gzip/Base64 data with unknown names | | Users | Administrators not visible in the Dashboard or accounts without proper rights | | Cron | Unknown scheduled tasks unrelated to site activity | | Database trigger | Unknown triggers that serve to recreate administrator accounts | | Memory | Presence of PHP code in System V shared-memory | | Network | Unexpected outputs from public Ethereum RPC gateways from the web server | | Code markers | Markers similar to SC_ prefix or constants like SC_AUTO_PREPEND | Important: Some of the file names above were observed in the specific example by Sucuri. They do not necessarily have to be the same on all infected sites. According to Sucuri's data, some file names may change depending on the site. How to clean the infection? When a malicious program that restores itself like SC is detected, randomly deleting components is not recommended. A backup copy and as much forensic copy should be kept before cleaning. According to Sucuri's recommendations, it is important to first stop the execution of the malicious code, then eliminate its copies outside the disk, and then clean the files. Practically, it is necessary to pay attention to the following sequence: 1. Temporarily stop the execution of malicious code. Identify and safely neutralize directives like auto_prepend_file. PHP caching mechanisms must be taken into account. 2. Check the database. Search for unknown options, transients, large amounts of encoded data, and malicious triggers. 3. Check Cron and other scheduled tasks. Unknown cron hooks may be running the malicious program. 4. Check administrator accounts. Review all high-privilege users, identify unknown accounts, and delete them if necessary. 5. Check the mu-plugins catalog. Components not visible in the simple plugins list must be checked separately. Plugins are recorded in WordPress documentation as loading automatically and operating separately from the regular plugin list. 6. Recheck WordPress, plugin, and theme files. In addition to deleting malicious components, any changes made to legal files must also be identified. 7. Check server memory. If the environment supports it, check for malicious PHP copies in shared-memory segments. 8. Full rescan. Recheck the site after cleaning and monitor for the reappearance of malicious components. 9. Close the entry point. If the malicious program used an old WordPress, plugin, theme, hosting panel, or modified administrator account, this entry point must be eliminated. 10. Change all important passwords and keys. WordPress administrators, hosting, FTP/SFTP, SSH, database, API keys, and other relevant account information must be updated. How to protect against such attacks? WordPress's official security recommendations recommend measures such as regularly updating the software, installing plugins and themes from trusted sources, creating backups, limiting file writing permissions, monitoring logs, and using WAF. Organizations should regularly implement the following measures for the desired outcome: - Regularly update WordPress core, plugins, and themes; - Delete unused plugins and themes; - Download plugins and themes only from trusted sources; - Regularly audit the mu-plugins catalog; - Monitor changes in wp-content and PHP configuration files; check unknown administrators, options, and triggers in the database; - Monitor cron tasks; - Filter malicious requests through WAF; - Use strong and unique passwords for administrator accounts; - Enable multi-factor authentication; - Centralize monitoring of server and WordPress logs; - Keep regular and reliable backups; - Use short-term API keys and tokens as much as possible; - Limit the ability to edit PHP files from the WordPress control panel. It is recommended to limit the ability to edit PHP files from the control panel in official WordPress documentation using DISALLOW_FILE_EDIT. This can reduce the possibility of directly modifying PHP code when an attacker has gained administrator access. The SC malicious program has shown how complex persistence mechanisms are in attacks against WordPress sites. Its main danger is not in a single malicious PHP file, but in a network of components that can restore each other. Files, WordPress plugins, mu-plugins, theme code, database, cron tasks, and even server memory copies can all fill each other up. Therefore, cleaning the site by simply deleting the malicious files is dangerous. It is necessary to identify all persistence points of the infection, eliminate the cause of the initial entry, update administrator and other authentication information, and re-monitor the cleaned site. Most importantly, if the deleted malicious file reappears, it should not be limited to simply deleting it. This may be an important sign that there is another hidden copy or restoration mechanism of the malicious program in the system.