Identifying WordPress Websites On Local Networks (behind Firewalls) and Bruteforcing the Login Pages

This article explores how attackers can leverage the XSHM attack to detect WordPress sites operating within internal networks or behind firewalls. It also demonstrates how this method can be used to carry out brute-force login attempts on these protected installations.

According to statistics from w3techs, approximately one in four websites on the internet—around 25%—use WordPress as their content management system. Its widespread adoption is largely due to its user-friendly setup, an active developer community, and the extensive collection of plugins and themes available, making it a preferred choice for both individuals and businesses. However, this popularity also makes WordPress a frequent target for attackers seeking vulnerabilities to exploit.

Why is WordPress a Frequent Target for Attacks?

Although WordPress is known for its ease of use and beginner-friendly interface, it also has security challenges like any other platform. One of the most commonly exploited vulnerabilities is brute-force login attacks, which allow attackers to repeatedly guess login credentials until they gain access.

To mitigate this risk, WordPress recommends users take additional security measures, such as:

• Installing security plugins
• Securing the login page with .htpasswd (HTTP authentication)
• Using strong and unique passwords

However, many users—particularly those with little experience—fail to implement these precautions. Weak credentials and the lack of additional security layers make WordPress sites an attractive target for brute-force attacks, allowing attackers to easily compromise accounts and gain unauthorized access.

Brute-Forcing WordPress Sites on Internal Networks and Behind Firewalls

WordPress is not only used for public-facing websites but is also commonly deployed on internal networks for intranet portals used by employees. These intranet sites are typically protected by firewalls and are not accessible from the internet. However, despite being isolated, they remain vulnerable to brute-force attacks.

Attackers can exploit the XSHM technique to brute-force WordPress login credentials on internal networks, even without direct access to the intranet site. This method allows attackers to interact with the WordPress login page and attempt credential guessing, bypassing traditional network restrictions and exploiting security gaps in the system.

Understanding XSHM (Cross-Site History Manipulation)

XSHM, short for Cross-Site History Manipulation, is a security vulnerability that exploits a weakness in the Same-Origin Policy (SOP). SOP is a browser security mechanism that prevents one website from directly accessing content from another when both are open in the same browser session. This policy is designed to prevent unauthorized data sharing between different sites.

However, side-channel attacks can still be used to extract certain information, even when SOP is enforced. XSHM is one such technique, allowing attackers to infer details about a user’s interaction with a website by analyzing browser history behavior.

How XSHM Works

An attacker can manipulate browser history using iframes and conditional redirects to determine whether a user is logged into a WordPress site (or another target website). Here’s how it works:

1. The attacker embeds an iframe on a malicious website (site A) and points it to a specific page on the target website (site B) that has a conditional redirect. For example, the iframe loads login.php, which redirects to index.php if the user is already logged in.
2. The attacker records the history.length value from the user’s browser tab.
3. The iframe is then updated to load index.php directly.
4. When the user accesses the iframe again, the attacker checks the new history.length value and compares it with the previous one.
5. If the history.length value remains the same, it means the browser did not register a new entry—indicating that the user was redirected from login.php to index.php. This confirms that the user is already logged into the WordPress site.

Why This Matters

Although the attacker cannot see the contents of the WordPress session directly, XSHM allows them to determine whether a user is logged in. This information can then be used in further attacks, such as brute-force attempts on internal network sites or targeted phishing attacks.

Detecting WordPress Sites on a Local Network

WordPress has a distinctive redirect behavior that makes it easy for attackers to identify sites running on the platform. If a user who is not logged in attempts to access the /wordpress/wp-admin/ page, WordPress automatically redirects them to the login page with the following URL format:

/wp-login.php?redirect_to=http%3A%2F%2Fexample.com%2Fwordpress%2Fwp-admin%2F&reauth=1  

This predictable redirection pattern allows attackers to scan networks for WordPress installations.

Using XSHM to Locate WordPress Sites

An attacker can leverage Cross-Site History Manipulation (XSHM) to detect WordPress instances within an internal network. This can be done by:

• Sending a malicious link to a victim, which contains an XSHM payload designed to test for WordPress redirects.
• The payload attempts to trigger the /wordpress/wp-admin/ redirect on a range of internal IP addresses (e.g., 192.168.1.1/24).
• If the redirection occurs, it confirms that a WordPress site is hosted at that internal IP.

Using JavaScript to Scan Internal Networks

Attackers can also deploy JavaScript-based network scanning techniques to detect WordPress installations within an internal network. One effective approach involves:

• Utilizing WebRTC (as implemented in frameworks like BeEF) to identify active internal hosts.
• Narrowing down the list of potential live systems within the network.
• Checking each detected host for the WordPress login redirect to confirm its presence.

Once the scanning process is complete, the attacker will have a list of internal IP addresses running WordPress. This information can then be used for further exploitation, such as brute-force login attempts or targeted attacks.

How XSHM Enables Brute-Force Attacks on WordPress Logins

Once an attacker has identified WordPress sites within an internal network, they can proceed with brute-force login attempts using XSHM, even without direct access to the target. This is possible because WordPress does not implement CSRF tokens in its login process, making it vulnerable to cross-site request forgery (CSRF) attacks.

The Importance of CSRF Tokens in Login Forms

There is a common misconception about whether CSRF protection is necessary for login forms. In reality, CSRF tokens are essential to prevent unauthorized login attempts. Without them, various attack vectors can be exploited, including:

• Session hijacking: An attacker can trick a user into unknowingly logging into the attacker’s account, allowing them to steal private information.
• Stored XSS exploitation: An otherwise unreachable stored cross-site scripting (XSS) vulnerability could be triggered after login.

Exploiting WordPress’ Redirect Feature

WordPress includes a redirect_to field in its login form, which determines where a user is redirected after a successful login. Attackers can abuse this feature in an XSHM-based brute-force attack, using a CSRF attack delivered via GET parameters.

Steps of the Attack

1. The attacker retrieves the history.length value of the victim’s browser tab.
2. An iframe is embedded on a malicious website, pointing to a self-submitting form that attempts to log in using a username/password combination.
3. After submitting login credentials, the iframe is updated to redirect_to a specific page, controlled by the attacker.
4. The attacker checks the new history.length value.
5. If the history.length remains unchanged, it indicates that WordPress redirected the user successfully—meaning the brute-force attempt worked, and the attacker has found a valid username-password pair.

Why This Works

Normally, Same-Origin Policy (SOP) would prevent an attacker from directly observing login outcomes. However, XSHM circumvents this restriction by leveraging browser history tracking. Since WordPress does not prevent login requests from cross-site sources, attackers can brute-force credentials without needing direct access to the login page.

This method highlights the critical need for CSRF protection in login forms, as well as other security measures such as two-factor authentication (2FA) and rate limiting to mitigate brute-force attacks.

Challenges and Limitations of the WordPress Login Attack Using XSHM

While the XSHM-based brute-force attack on the WordPress login page is a viable technique, it comes with several limitations that make it difficult to execute successfully.

User Interaction is Required

For the attack to work, the attacker needs at least two interactions from the victim:

1. Visiting a malicious webpage – The victim must first land on a site controlled by the attacker.
2. Manually opening a new browser tab or window – Due to modern popup blockers, a new tab cannot be opened automatically. The victim must click a button or link, making the attack harder to execute unnoticed.

The Attack is Easily Detectable

Since the exploit relies on the user actively opening a new tab, the victim is likely to notice unusual behavior, such as:

• A new tab or window opening unexpectedly.
• A page refresh that may draw attention.

Because of these visual indicators, the likelihood of the attack going unnoticed is very low.

Issues with iframe Restrictions

Attackers cannot embed the WordPress login page inside an iframe due to X-Frame-Options, a security header that prevents sites from being loaded within an iframe to mitigate clickjacking attacks.

This creates additional problems:

• In certain web browsers, history.length might not increase when X-Frame-Options is enabled.
• Without this increase in history length, the attacker cannot reliably determine whether the WordPress site exists or if a login attempt was successful.

While the XSHM-based WordPress brute-force attack is technically possible, its reliance on user interaction, visual indicators, and security headers significantly reduce its effectiveness. As a result, attackers may find it difficult to execute this method without raising suspicion.

Challenges Due to Browser Behavior

One of the key obstacles in executing an XSHM attack is the inconsistent behavior of different web browsers. Some browsers, like Google Chrome, always modify the history.length value even if the attacker redirects an iframe to its existing source. This behavior seems to act as a countermeasure against XSHM, causing the attack to fail.

Using window.opener to Circumvent Limitations

To work around this restriction, attackers can exploit window.opener, a JavaScript property that allows a newly opened browser tab or window to access and modify its parent window’s properties. This method enables attackers to bypass history length restrictions and X-Frame-Options protections.

How the Attack Works

Instead of relying on iframes, the attacker manipulates a new browser tab using the following steps:

1. The attacker’s malicious page (attacker.com/opener.html) opens a new tab that loads another attacker-controlled page (attacker.com/child.html).
2. In the child window, the attacker accesses opener.history.length to record the parent tab’s history length.
3. The child window then sets the parent window’s location to http://192.168.1.123/wordpress/wp-admin/, attempting to trigger a WordPress login redirect.
4. The attacker modifies window.opener.location to point to:

http://192.168.1.123/wordpress/wp-login.php?redirect_to=http%3A%2F%2F192.168.1.123%2Fwordpress%2Fwp-admin%2F&reauth=1  

 

This forces a redirection to the WordPress login page.

 

5. The parent window’s location is then reset back to attacker.com/opener.html, restoring the same-origin environment.
6. The attacker retrieves opener.history.length again and compares it to the value recorded in step 2.

Why This Works

By manipulating window.opener, the attacker bypasses iframe restrictions and avoids X-Frame-Options protections. Since the attack is carried out in a separate browser tab, it also becomes harder for the victim to detect the intrusion.

Using Popunders for Stealth

To make the attack even less noticeable, attackers can use popunder windows—background browser tabs that are opened without drawing attention. This technique ensures that the victim remains unaware while the attack takes place in the background.

Although some browsers implement defensive mechanisms against XSHM, attackers can still work around these restrictions by leveraging window.opener to manipulate browser history, bypassing security features like X-Frame-Options and evading detection.

Limitations of the history.length Property in XSHM Attacks

One obstacle that can interfere with Cross-Site History Manipulation (XSHM) attacks is the maximum limit of the history.length property. In Google Chrome, for instance, the maximum number of history entries is 50. Once this limit is reached, the oldest entries are removed as new ones are added. This can be problematic for attackers relying on history length to track redirections.

Bypassing the History Length Limitation

To work around this limitation, an attacker can manipulate the window.opener object with the following steps:

1. Trick the victim into visiting a same-origin URL using window.opener.location.
2. Force the victim’s browser to navigate back to the first page in the current session using:

window.opener.history.go(-(window.opener.history.length – 1))

 

This determines how many pages the user can go back and returns to the oldest entry.

 

3. Set the URL to a new page, increasing the history length to 2.

 

By resetting the session history in this way, the attacker can bypass the 50-entry limit and continue tracking user behavior for the XSHM attack.

Overcoming Logout CSRF Protection

Another challenge for XSHM-based WordPress brute-force attacks is logout CSRF protection. If a user is already logged in, the attacker cannot reliably determine whether a WordPress installation exists or execute a login brute-force attempt.

Leveraging WordPress’ Behavior for an Attack

WordPress has a unique feature that makes it an exception in this case. When a user visits wp-login.php, the system always displays a login prompt, regardless of whether the user is already authenticated. While this helps an attacker attempt brute-force login attempts, it still does not guarantee a definitive way to confirm a WordPress installation on the target server.

Exploiting the reauth Parameter

WordPress provides an additional reauth parameter, which can be used to force a logout when visiting wp-login.php. By setting reauth=1, the attacker can automatically log the user out:

http://target-site.com/wp-login.php?reauth=1

Once the victim is logged out, the attacker can:

1. Redirect the user to /wp-admin/.
2. Observe if the system redirects back to wp-login.php.
3. If redirection occurs, it confirms that WordPress is installed on the target server.

Although history length limits and logout CSRF protection pose challenges for XSHM attacks, attackers can still manipulate browser behavior using window.opener tricks and WordPress’ reauth parameter. These methods allow them to identify WordPress installations, perform brute-force attacks, and track user authentication status without direct access to the system.

How to Defend Against XSHM Attacks

As a WordPress user, you cannot directly prevent XSHM attacks, as they exploit browser behavior rather than vulnerabilities in WordPress itself. Mitigation depends on the website developers implementing proper security measures to reduce the risk of such attacks. Effective countermeasures include:

• Avoiding conditional redirects that unintentionally expose sensitive information.
• Implementing CSRF tokens to prevent unauthorized authentication requests.
• Randomizing URL structures, even without linking them to application logic. This makes it harder for attackers to predict the exact redirection path and manipulate it for exploitation.

Practical Impact of the Attack

Although there is a proof of concept demonstrating how XSHM can be used to attack WordPress, its real-world application is limited. The attack requires detailed knowledge of the target system, and its success depends on the victim spending an extended period on the attacker’s website while an obvious page refresh occurs in a visible browser window. These challenges make widespread use of the attack impractical.