Signs your Magento or WordPress site was hacked, and what to do

A hacked online store rarely looks like it does in the movies. Usually everything seems normal: orders come in and pages load, while someone collects card data on the checkout, search engines show spam under your domain and your server sends out someone else's email. Here are the signs that a Magento or WordPress site has been hacked, how to check quickly, and what to do if your suspicion turns out to be right.

Signs your site was hacked

• Redirects and search spam. Visitors from search or on mobile end up on other sites, and a site:your-domain search in Google shows pages you never created, often about pharmacy, casinos or in Japanese. This spam is often shown only to search engine crawlers, so you may not see it yourself.
• Google and browser warnings. "This site may be hacked" in search results, a red warning page in the browser, an email from Search Console. Your customers' antivirus software starts flagging your site.
• New administrators. Admin users nobody created, or existing accounts with a changed email address or new permissions.
• Unknown and modified files. PHP files in upload and media folders, files with odd names in the site root, recently changed index.php, .htaccess or theme files.
• Unfamiliar JavaScript on the checkout. For Magento this is the main risk: a skimmer (these attacks are known as Magecart) is injected into the payment page and sends card details to the attackers. The customer notices nothing, and the order goes through. Some skimmers show a fake payment form and then pass the shopper on to the real one.
• Complaints about card fraud. Customers report fraudulent charges after buying from you, your bank or payment provider asks about a possible breach, and chargebacks go up.
• Odd cron jobs and processes. New crontab entries and processes that load the CPU for no reason. Miners and backdoors that reinstall themselves after removal often work this way.
• Load and email. A sudden rise in outgoing traffic or server load without more sales, spam complaints about your IP, your host suspending the site.

How to check

No single tool shows everything: external scanners see what a visitor sees, while server-side checks look at files and the database. It is better to go through several steps.

1. Google Search Console. The Security issues report shows when Google has decided your site was hacked or could harm visitors, with sample URLs. If your site is not in Search Console yet, add it. It is free.
2. Scanners. For Magento, Adobe offers the free Security Scan Tool in your Commerce/Magento account: it looks for malware, skimmers, missing security patches and vulnerable extensions, and can run on a schedule. Sansec's eComscan is a commercial server-side scanner built for online stores. For WordPress there are free plugins in the WordPress.org directory, such as Wordfence; WordPress.org itself recommends combining an on-site scanner with external checks such as VirusTotal.
3. Compare with a clean copy. In WordPress, wp core verify-checksums checks core files against WordPress.org checksums, and wp plugin verify-checksums --all does the same for plugins from the official directory. For Magento, set up a clean copy of the same version with Composer and compare the vendor, app/code and pub folders with production.
4. Recently modified files. For example, find . -type f -name '*.php' -mtime -14 lists PHP files changed in the last two weeks. Attackers can fake file dates, so an empty result proves nothing.
5. Users in the database. In Magento, check the admin_user table for recently created accounts and unfamiliar email addresses. In WordPress, run wp user list --role=administrator or check the wp_users table.
6. Scripts in Magento settings and blocks. Skimmers are often hidden in the database rather than in files: in core_config_data (for example the HTML Head and footer settings, paths design/head/includes and design/footer/absolute_footer) and in cms_block. Look for <script> tags you did not add.
7. Logs. Web server logs: POST requests to unfamiliar PHP files, admin logins from unknown IPs. Admin login history and configuration changes.

What to do if the site is hacked

1. Don't delete everything suspicious right away. First write down what you see and when you noticed it, and take a server snapshot or a full copy of files and database, even an infected one. Without it you won't be able to tell how the attacker got in or what they took.
2. Stop the damage. If there is a skimmer on the checkout, close checkout or put the store into maintenance mode until you are sure the code is gone. Check whether other sites on the same server or hosting account are affected.
3. Change every credential. Admin passwords, SSH and SFTP, hosting panel, database, API keys for payment and other integrations. In WordPress, replace the secret keys in wp-config.php, which logs everyone out. In Magento, change the encryption key (bin/magento encryption:key:change; Adobe describes the procedure in its knowledge base) and integration tokens. Change passwords once more after the cleanup.
4. Find the entry point. A missing patch, a vulnerable extension, a stolen password, an infected developer laptop. Until it is closed, the site will be hacked again, sometimes the same day. Recent examples of such vulnerabilities are BlockStrap in Magento and PHP2Shell in PHP itself.
5. Clean up or restore. The most reliable option is to restore the site from a backup taken before the compromise and apply updates right away. Without a clean backup, reinstall the core and modules at the same version and review your own code and database by hand.
6. Update. CMS, extensions, PHP, the server. For Magento, every security patch, including isolated patches.
7. Notify the people involved. If personal data of EU customers leaked, the GDPR requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. If card data leaked, tell your payment provider or acquiring bank: they have their own requirements and deadlines. If the site was blocklisted, request a review in Search Console after the cleanup, not before: a premature request can make the review take longer.

How to keep it from happening again

• Install security patches as soon as they come out, especially critical ones, not once every six months.
• Remove unused extensions and plugins, and keep the rest up to date.
• Two-factor authentication for every administrator, unique passwords, personal accounts instead of a shared "admin".
• Regular backups stored away from the server, which you have tried restoring at least once.
• Continuous monitoring: scheduled scans, alerts on new administrators and file changes.

We have been working with Magento and PHP projects for more than ten years. If you suspect a compromise, we will inspect the site and server, find the entry point, remove the malicious code, apply updates and set up monitoring so it doesn't happen again.

Sources: Search Console Security issues report, Adobe Security Scan Tool, Adobe on encryption key rotation, WordPress.org: My site was hacked, wp core verify-checksums, wp plugin verify-checksums, Sansec on modern skimmers, GDPR Article 33.