Redirected, Taken Over, & Defaced: Breaking Down the Attacks Abusing Legitimate Hong Kong Websites
Last week, we shared our observations regarding active attacks weaponising trusted Hong Kong domains to serve users to suspicious content for SEO manipulation purposes. Collectively, we have observed over 70 cases of open redirect attacks, web defacements, and/or subdomain takeovers in Hong Kong between January and April 2025. These attacks, specifically those related to online gambling content, are observed via open-source intelligence to be part of a wider trend impacting victims across the Asia Pacific.
In this part two of the series, we dive into the technical – breaking down how these techniques work, what technologies and vulnerabilities are often involved, and how you can prevent and defend against these threats.
Read Part One here: Redirected, Taken Over, & Defaced: Legitimate Hong Kong Websites Abused to Serve Users to Online Gambling and Adult Content
Open Redirects Weaponise Trusted Hong Kong Websites
This technique is not novel by any means; open redirection first garnered attention in the early 2000s as web applications began incorporating user-controllable data into redirection targets without proper validation. When the input is improperly validated, malicious actors may exploit this vulnerability by crafting URLs that redirect users to malicious sites – leveraging the trust of the original, legitimate (sub)domain.
The typical attack flow is as follows:
- Register new domain to host malicious content
- Compromise legitimate, trusted domains susceptible to open redirections
- Perform SEO manipulation to deliver the webpage, increasing user traffic to their malicious sites
- User searches for intended site via a search engine, clicks on link shown in search results, and is redirected to the malicious site
Certain subdomains face higher risk of open redirection abuse. Login, registration, password resets, and checkout pages are a few examples. These pages naturally face higher likelihood of this abuse as redirection is an integral part of their workflows. Ensuring proper validation of redirect URLs on these pages is crucial to prevent potential exploitation.
1. Vulnerable or Misconfigured Web Applications
Threat actors often target PHP-based applications as it is one of the most widely used server-side scripting languages for web development. This allows for the ability to actively scan and exploit vulnerable PHP webapps at scale. Furthermore, PHP applications often suffer from common and easily exploitable misconfigurations that can expose servers to open redirect vulnerabilities. Part of the reason for this is that many PHP applications run on legacy code, that may not have been updated to follow modern security practices.
Case Study #1: Moodle
Notably, we have observed recurrent weaponisation of higher education domains, which we partially attribute to the fact that the widely used Moodle Learning Management System (LMS) platform is built in PHP. In the screenshots below, we highlight a recent case whereby a legitimate higher education website was abused to redirect to an illicit Indonesian online gambling site. This aligns with public reporting of an ongoing campaign targeting PHP servers with PHP backdoors and the GSocket networking tool to serve users to illicit Indonesian gambling sites.[1]
Case Study #2: WordPress
WordPress is another popular PHP-based application that often faces open redirect vulnerabilities (e.g., CVE-2024-4704 [2]), primarily given the use of third-party plugins and insufficient patch management. Recently, we identified a Hong Kong domain redirecting to YouTube videos. We assessed the likely root cause to be exploitation of known vulnerabilities impacting PHP to allow for redirects. We posit that this redirection to YouTube videos may have been motivated by traffic monetisation; whereby the threat actor may have joined an affiliate program or ad network to generate site visits in return for payment.
Case Study #3: Vulnerable WordPress Plugin Leads to Web Defacement
Whilst malicious actors do not need to infiltrate the victim environment to compromise their website for open redirection, in some cases we do observe threat actors gain internal access to compromise – or deface – sites for SEO poisoning. In a defacement attack, malicious actors obtain unauthorised access to a website, garnering the ability to modify the website contents, as well as other malicious activities such as deploying a web shell or establishing connection with their C2 for persistence.
In late 2024, we responded to an incident whereby a financially-motivated threat actor infiltrated the victim’s site via exploitation of the WordPress plugin GutenKit (CVE-2024-9234). The threat actor weaponised the vulnerable plugin to install various PHP-based web shells, facilitating additional access to multiple subdomains within the website’s directory, and uploads of gambling-related web contents.
Based on the language indicators contained within the web shell, as well as the displayed content on the defaced subdomains, we assessed the attack was performed by an Indonesian threat actor. Notably, our analysis of the web shells suggested that the Telegram API bot was embedded within. Notably, the bot is known to facilitate SEO poisoning tactics – such as automation of tasks for an enhanced, efficient gambling experience, and affiliate marketing.[3],[4]
Microsoft IIS Servers (and ASP.NET)
Microsoft Internet Information Services (IIS) servers are frequently abused for open redirections due to their widespread use, configuration complexity, and presence of legacy systems. IIS servers often host ASP.NET applications, which can be susceptible to open redirect attacks if not properly secured. This is due to ASP.NET applications typically using query strings and form data for redirection, which can be manipulated by malicious actors if not validated.
Case Study #4: IIS Server hosting PHP and ASP.NET
PHP and IIS can work together to host PHP applications on Windows servers. This is evidenced below, as we observed multiple subdomains abused to redirect users to adult content sites. We hypothesise the purpose of directing users to these sites is likely to further redirect users to phishing sites to gather personally identifiable information (PII), extort victims via cheating scandals[5], or deliver malware.
2. Other issues that could lead to open redirection abuse
In addition to vulnerable or misconfigured web applications, there are alternative means in which threat actors may exploit web servers for open redirection.
Content-Security-Policy – “unsafe-allow-redirects”
Content-Security-Policy (CSP) is a HTTP security feature that allows website administrators to specify which sources of content are trusted and can be safely loaded by the browser. Unsafe-allow-redirects in a CSP allows for redirects, including HTTP status codes like 301, 302, 307, and 308, as long as the final destination complies with the CSP. This could potentially permit redirects leading to untrusted or potentially harmful sites, and is a feature that should be used with caution. To safely utilise unsafe-allow-redirects, strict whitelisting is recommended, further supplemented with ongoing monitoring and periodic audits of the overall CSP to adapt to the latest threats and ensure it remains effective.
Case Study #5: unsafe-allow-redirects
In this case, we detected a local government website abused to route traffic to adult content sites. Upon examining the impacted subdomain, we observed the unsafe-allow-redirects feature enabled. As at the time of our investigation, it was observed the redirection links had become invalid and no longer functional. However, the cached redirect meant that the links still displayed in search results – posing potential reputational damage, even if the links were no longer active.
Leaked FTP Credentials
In other cases, threat actors weaponise valid File Transfer Protocol (FTP) credentials to facilitate their open redirection attacks. These credentials are likely obtained via the dark web, and are leveraged to inject JavaScript code into websites. In these cases, the threat actor would possess the ability to perform additional malicious activities such as defacement or potential data exfiltration, given internal access to victim environments. In late 2022, researchers tracked a campaign weaponising legitimate websites intended for East Asian audiences to direct users to adult-themed content.[6]
Subdomain Takeover to Display Indonesian Gambling Sites
In addition to using open redirects, malicious actors have been observed to exploit expired domains for subdomain takeovers to display Indonesian gambling content. A subdomain takeover occurs when a subdomain (e.g., sub.example.com) points to a removed or deleted service, leaving the CNAME record in the Domain Name System (DNS) still active – a “dangling” DNS entry. This creates an opportunity for attackers to provide their own virtual host and host their content.
The typical attack flow is as follows:
- Creation: An organisation creates a new subdomain, which is assigned a CNAME record pointing to a service (e.g., sub.example.com pointing to
sub-service.provider.com). - Deprovisioning: The service is removed or deleted, but the CNAME records remains existing within the DNS, creating a “dangling” DNS entry.
- Discovery: A malicious actor discovers the dangling subdomain via automated scanning tools and/or manual checks.
- Takeover: The malicious actor provisions a new service with the same fully qualified domain name (FQDN) as the original (e.g.,
sub-service.provider.com). - Redirection: Traffic intended for the original subdomain is now redirected to the attacker’s service, allowing them to host their own content.
Case Study #6: Wix Subdomain Takeover
In early 2025, we notified a local education victim regarding the compromise of their subdomain to display Indonesian gambling content. The impacted subdomain was observed to be hosted on Wix and intended for a short-term event-related campaign; hence the eventual deprovisioning of the site.
The threat actor discovered the dangling DNS entry and proceeded to create a new Wix site displaying gambling-related content, and assigned it with the same subdomain as observed in the CNAME record ([redacted].wixdns.net). As a result, any new traffic to the subdomain would be directed to the attacker’s Wix site.
Case Study #7: Azure Subdomain Takeover
In another case, we observed a subdomain pointing to an Azure service which was compromised to also display Indonesian gambling content. The attack flow remains the same; the Azure service (e.g., sub-service.azurewebsites.net) is deleted, leaving the CNAME record dangling. The attacker discovered this, and subsequently provisioned a new Azure service with the same FQDN (sub-service.azurewebsites.net).
Subdomains hosted on Azure face a relatively heightened risk of CNAME takeover. This is given the CNAME is unique – making it easier for attackers to take over the dangling DNS, whilst in the case of Wix the CNAME is not unique and attempts may not always result in a successful hijacking. Generally speaking, any services used whereby subdomains can (and are) being easily created/deleted are at risk of leaving dangling DNS records if the appropriate remediation steps are not implemented.
Conclusion
As evidenced through our ongoing monitoring, SEO poisoning attacks show no signs of slowing down. These attacks pose a significant and growing threat, primarily impacting reputational integrity, user trust, and potentially leading to legal consequences. However, the danger extends beyond these immediate risks. Attackers with internal access can escalate their malicious activities, deploying web shells, performing lateral movements, and engaging in extortion through data exfiltration or ransomware.
As these campaigns increase in frequency and sophistication, it is imperative for organisations to stay vigilant and implement robust security measures. Regular security audits and proactive configuration assessments are essential to minimize vulnerability to such attacks. By maintaining a strong security posture, organisations can protect their reputation, uphold user trust, and prevent their brand from being exploited for malicious purposes.
Why are these attacks persisting? Read Part One: Redirected, Taken Over, & Defaced: Legitimate Hong Kong Websites Abused to Serve Users to Online Gambling and Adult Content
Recommendations and Best Practices
Minimise the threat of open redirect abuse:
| Prevention | Avoid user-controllable data in URLs where possible. Per OWASP’s CheatSheet to prevent unvalidated redirects and forwards[7]; – Do not allow the URL as user input for the destination. – Implement access controls to restrict unauthorised modifications – such as requiring the user to provide short name, ID, or token which is mapped server-side to a full target URL. – Appropriate checks to validate the supplied value is valid, appropriate for the application, and authorized for the user. – Sanitise input by creating an allowlist of trusted URLs (e.g., hosts or regex). – Ensure all redirects first notify users that they will be redirected to another site, clearly displaying the destination URL, and requiring the user to click a link to confirm. Detailed recommendations for validating and sanitising user-inputs here.[8] |
| Detection | – Deploy continuous, automated attack surface monitoring to proactively detect, validate (e.g., simulate payload injection), and remediate URLs vulnerable to open redirection attacks. – Use regular expressions (regex) patterns to scan web server logs for suspicious redirection patterns (e.g., URLs that include external domains in redirection parameters). – Implement logging and monitoring of redirection activities; analyse logs for unusual redirection patterns (e.g., frequent redirections to external sites). |
| Remediation Steps | If your website has fallen victim to open redirection: – Disable the affected URL(s) to prevent further abuse. – Conduct a thorough investigation to identify the vulnerability exploited and extent of the abuse. – Apply necessary patches and hardening measures to secure the website against similar attacks. – Perform an audit to ensure no other websites have been compromised. – Inform users regarding the incident and provide advice on steps taken to secure their data and the website. |
| Individuals’ User Awareness | Users should perform checks to validate the legitimacy of the website they are providing information to. Recognise suspicious URLs and websites: – Before clicking link, hover over the link to see the actual URL. – Check for spelling or grammatical errors in the domain name and website contents itself (e.g., brand name spelled wrong). – Ensure URL is secure (HTTPS rather than HTTP). – Trust your browser; modern browsers often warn you if you are about to visit a suspicious or known phishing site. – Use online URL scanners, such as VirusTotal, to determine if the website has been flagged as malicious. Other indicators observable from these platforms is the recency of the domain creation (e.g., newly created domains could indicate it to be phishing). |
| Compliance and Legal Considerations | May involve legal responsibilities related to protecting user data and preventing phishing attacks. |
Minimise the threat of subdomain takeovers and defacements:
| Prevention | Reduce your “low hanging fruit” through continuous attack surface monitoring to proactively identify and remediate potential entry points; – 24×7 dark web monitoring to swiftly detect and remediate compromised data (e.g., leaked credentials from infostealer dumps). – 24×7 social media listening and brand reputation monitoring to identify mentions or impersonation attempts of your organisation. – Consider an offensive approach to Threat and Vulnerability Management for real-time visibility of your attack surface through autonomous, rapid detection and remediation. – 24×7 young domain monitoring to proactively uncover potential phishing campaigns impersonating your organisation. – Regularly perform security audits and penetration tests to identify and fix misconfigurations in your web applications and servers. Ensure secure coding practices are enforced. – Maintain an up-to-date inventory and establish a prioritised patch management plan to ensure rapid patching for technologies known to be frequently abused by threat actors. – Review and harden Internet-facing applications’ access controls and safeguards (e.g., web application firewall, password policies, multi-factor authentication, etc.). – Regularly audit your DNS records to identify and remove any CNAME records pointing to deprovisioned services. – Enforce a strict policy to standardise the deprovisioning of resources (e.g., ensuring DNS entries are removed once the service is deprovisioned). |
| Detection | – Consider implementation of real-time monitoring of DNS changes, including updates to CNAME records, to detect and remediate any unauthorised modifications. – Consider implementation of a File Integrity Monitoring (FIM) solution on backend servers (e.g. IIS) to monitor for anomalous file modification activity (e.g. file creation, modification, or deletion). Alternatively, consider the use of canary tokens to detect for defacement attacks. For example; – Webpage monitoring – embed canary tokens within webpages. If any unauthorised modifications are detected, this will trigger an alert. – File integrity monitoring – canary tokens may be placed in critical files on your web server. If these files are accessed or altered, the token will trigger an alert. |
| Remediation Steps | If your website has fallen victim to a defacement: – Take the affected page offline to prevent further damage. – Conduct a thorough investigation to determine the root cause and extent of the breach. Given unauthorised access to internal environments, ensure to check for other malicious activities such as lateral movement, credential harvesting, deployment of web shells or other malware, etc. – Apply necessary patches and updates to remediate vulnerabilities. Further, refer to and implement the preventive and detective recommendations above. – Restore the webpage from your latest, clean backup. – Notify all relevant stakeholders regarding the incident and the steps being taken to address it. |
| Compliance and Legal Considerations | May involve legal implications such as complying with data protection regulations, notifying affected users and stakeholders, and maintaining thorough documentation to demonstrate due diligence. |
Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.
