sc_, wp_custom_ options and rogue crons: spam hidden in the WordPress database

Inspecting your database, you came across odd rows in the wp_options table: names starting with sc_, wp_custom_ or home_links_custom_ that you never created. That’s database spam persistence — a mechanism that stores the malware’s configuration, and sometimes its code, directly in the database to survive a file cleanup.

What is it?

WordPress stores its settings in the wp_options table. SEO/spam malwares exploit it to hide their configuration there: redirect destinations, the list of links to inject, code to execute, or a re-infection marker. The prefixes we see most often on the sites we clean are sc_, wp_custom_ and home_links_custom_ — none of which match a native WordPress option. They regularly come with malicious scheduled tasks (crons) named sc_cron, _dropper or evalcron, which re-inject the spam at regular intervals.

This is the “database” half of an infection. The other half is in the files. The two regenerate each other.

Symptoms

• Unknown sc_*, wp_custom_*, home_links_custom_* options in wp_options.
• Unknown scheduled tasks (visible via a plugin or wp cron event list).
• Spam or links you didn’t create that reappear after deletion.
• A redirect whose destination seems “stored” somewhere.

How to check if you’re infected

In the database (phpMyAdmin or WP-CLI):

wp option list --search='sc_*'
wp option list --search='wp_custom_*'
wp option list --search='home_links_custom_*'
wp cron event list

In direct SQL:

SELECT option_name FROM wp_options
WHERE option_name LIKE 'sc\_%' OR option_name LIKE 'wp\_custom\_%'
   OR option_name LIKE 'home\_links\_custom\_%';

The free WP-Detox scan includes a database scan: it surfaces the injected options and malicious crons of this family, in addition to the files.

Removing it properly

The rule: never handle the database without handling the files at the same time, or one regenerates the other.

1. Back up the database before any deletion.
2. Remove the options sc_*, wp_custom_*, home_links_custom_* (after checking they don’t belong to a legitimate plugin).
3. Delete the malicious crons (sc_cron, _dropper, evalcron).
4. Clean the file side in parallel: that’s what recreates the options. Hunt for the backdoor and injected code that rewrite these rows.
5. Purge the already-published spam — see removing casino spam posts.
6. Close the flaw and rotate credentials.

How it comes back (persistence)

This kind of infection is built to resist partial cleanups: if you delete the files but leave the options and the cron, the scheduled task redeploys the malware; if you empty the database but leave the backdoor, the file rewrites the options on the next request. Persistence is cross-linked between database and files. The only cleanup that holds handles both in the same pass.

FAQ

I deleted the sc_ options but they come back, why? Because a malicious cron or a backdoor in the files recreates them. Database persistence and file persistence work together: as long as the file that re-injects isn’t removed, deleting the database rows won’t hold. You have to handle both.

Is it risky to delete these options directly in the database? These prefixes (sc_, wp_custom_, home_links_custom_) match no standard WordPress option or common plugin; removing them is safe for the site. Always back up the database first, and check an option doesn’t belong to a legitimate plugin you use.

Can these options re-infect the files? Yes. Some store code or configuration that the file side of the malware reads and executes. The database isn’t just a passive store: it’s part of the mechanism. That’s why a cleanup must cover files AND database.

---

At WP-Detox, our scan covers files and database: injected options, rogue crons and published spam are handled in the same pass as the backdoors. The scan is free, the cleanup takes about 30 minutes, it’s €149 excl. VAT and refunded if the site isn’t clean. For the big picture, start with the complete guide to cleaning a hacked WordPress.