English Threat Research Center Threat Research Malware MALWARE The Next Frontier of Runtime Assembly Attacks: Leveraging LLMs to Generate Phishing JavaScript in Real Time 9 min read RELATED PRODUCTS Advanced URL Filtering Cloud-Delivered Security Services Code to Cloud Platform Prisma AIRS Unit 42 AI Security Assessment Unit 42 Incident Response By: Shehroze Farooqi Alex Starov Diva-Oriane Marty Billy Melicher Published: January 22, 2026 Categories: Malware Threat Research Tags: API DeepSeek Google JavaScript LLM Phishing Share Executive Summary Imagine visiting a webpage that looks perfectly safe. It has no malicious code, no suspicious links. Yet, within seconds, it transforms into a personalized phishing page. This isn't merely an illusion. It's the next frontier of web attacks where attackers use generative AI (GenAI) to build a threat that’s loaded after the victim has already visited a seemingly innocuous webpage. In other words, this article demonstrates a novel attack technique where a seemingly benign webpage uses client-side API calls to trusted large language model (LLM) services for generating malicious JavaScript dynamically in real time. Attackers could use carefully engineered prompts to bypass AI safety guardrails, tricking the LLM into returning malicious code snippets. These snippets are returned via the LLM service API, then assembled and executed in the victim's browser at runtime, resulting in a fully functional phishing page. This AI-augmented runtime assembly technique is designed to be evasive: The code for the phishing page is polymorphic, so there’s a unique, syntactically different variant for each visit The malicious content is delivered from a trusted LLM domain, bypassing network analysis It is assembled and executed at runtime The most effective defense against this new class of threat is runtime behavioral analysis that can detect and block malicious activity at the point of execution, directly within the browser. Palo Alto Networks customers are better protected through the following products and services: Advanced URL Filtering Prisma AIRS Prisma Browser with Advanced Web Protection The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Related Unit 42 Topics JavaScript, LLMs, Phishing LLM-Augmented Runtime Assembly Attack Model Our previous research shows how attackers can effectively use LLMs to obfuscate their malicious JavaScript samples offline. Reports from other sources have documented campaigns that leverage LLMs during runtime execution on compromised machines to tailor attacks (e.g., LLM-powered malware and ransomware). Anthropic researchers have also published reports indicating that LLMs have aided cybercriminals and played a role in AI-orchestrated cyberespionage campaigns. Motivated by these recent discoveries, we researched how threat actors could leverage LLMs to generate, assemble and execute phishing attack payloads within a webpage at runtime, making it challenging to detect with network analysis. Below we outline our proof of concept (POC) for this attack scenario and offer steps to help mitigate the impact of this potential attack. Attack Model For Our PoC The attack scenario begins with a seemingly benign page. Once loaded in the victim's browser, the initial webpage makes requests for client-side JavaScript to popular and trusted LLM clients (e.g., DeepSeek and Google Gemini, though the PoC could be effective across a number of models.). Attackers can then trick the LLM into returning malicious JavaScript snippets using carefully engineered prompts that circumvent safety guardrails. These snippets are then assembled and executed in the browser's runtime to render a fully functional phishing page. This leaves behind no static, detectable payload. Figure 1 shows how we developed our PoC to leverage LLMs to enhance existing attacks and bypass defenses. The first two steps involve initial preparation, while the final step details the generation and execution of phishing code within the browser at runtime. Figure 1. Workflow of the PoC. The first two steps are initial preparation, and the third is an example of generating malicious content to be rendered in the browser. Step 1: Select a Malicious or Phishing Webpage The attacker’s first step would be to select a webpage from an active phishing or malicious campaign to use as a model for the type of malicious code that would perform the desired function. From there, they can create JavaScript code snippets that will be generated in real-time to dynamically render the final page displayed to the user. Step 2: Translate Malicious JavaScript Code Into LLM Prompts The attacker’s next step would be to craft prompts describing the JavaScript code's functionality to the LLM in plain text. They could iteratively refine prompts, generating malicious code that bypasses existing LLM guardrails. These generated snippets could differ structurally and syntactically, allowing attackers to create polymorphic code with the same functionality. Step 3: Generate and Execute Malicious Scripts at Runtime From there, attackers could embed these engineered prompts inside a webpage, which would load on the victim's browser. The webpage would then use the prompt to request a popular, legitimate LLM API endpoint to generate malicious code snippets. These snippets could then be transmitted over popular, trusted domains to bypass network analysis. Subsequently, these generated scripts could be assembled and executed to render malicious code or phishing content. How This Attack Technique Helps with Evasion This technique builds upon existing evasive runtime assembly behaviors that we often observe on phishing and malware delivery URLs. For example, 36% of malicious webpages we detect daily exhibit runtime assembly behavior, such as executing constructed child scripts with an eval function (e.g., retrieved, decoded or assembled payloads). Leveraging LLMs during runtime on a webpage gives attackers the following benefits: Evading network analysis: The malicious code generated by an LLM could be transferred over the network from a trusted domain, as access to domains of popular LLM API endpoints is often allowed from the client side. Increasing the diversity of malicious scripts with each visit: An LLM can generate new variants of phishing code, leading to higher polymorphism. This can make detection more challenging. Using runtime assembly and executing JavaScript code to complicate detection: Assembling and executing these code snippets during runtime enables more tailored phishing campaigns, such as selecting a target brand based on the victim's location or email address. Obfuscating code in plain text: Translating code into text for subsequent concealment within a webpage can be viewed as a form of obfuscation. Attackers commonly employ various conventional techniques (e.g., encoding, encryption and code fragmenting) to visually conceal malicious code and evade detection. While advanced analyses often identify conventional obfuscation methods by evaluating expressions, it will be more challenging for defenders to evaluate text as executable code without subjecting each snippet to an LLM. PoC Example In researching the PoC we were able to demonstrate how this augmentation could be applied to a real-world phishing campaign, illustrating its ability to enhance evasion techniques through the steps we outline above. A brief overview of this PoC is provided below. Step 1: Selecting a Malicious/phishing Webpage For our PoC, we replicated a webpage from an advanced real-world phishing campaign known as LogoKit. The original phishing attack uses a static JavaScript payload to transform a benign-looking web form into a convincing phishing lure. This script performs two key functions: personalizing the page based on the victim’s email in the address bar and exfiltrating captured credentials to an attacker's web server. Step 2: Translating Malicious JavaScript Code Into LLM prompts Our PoC uses a popular LLM service, accessible via a chat API query from within the browser's JavaScript. To mitigate potential misuse by attackers, we are not disclosing the name of this specific API. We used this LLM API to dynamically generate the code necessary for credential harvesting and impersonate target webpages. Because the malicious payload is generated dynamically in the browser, the initial page transmitted over the network is benign, allowing it to inherently bypass network-based security detectors. The attack's success hinged on careful prompt engineering to bypass the LLM's built-in safeguards. We found simple rephrasing was remarkably effective. For instance, a request for a generic $AJAX POST function was permitted (shown in Figure 2), while a direct request for "code to exfiltrate credentials" was blocked. Furthermore, indicators of compromise (IoCs) (e.g., Base64-encoded exfiltration URLs) could also be hidden within the prompt itself to keep the initial page clean. Figure 2. Example of prompt engineering to bypass LLM guardrails and generate JavaScript code for phishing content. The non-deterministic output of the model provided a high degree of polymorphism, with each query returning a syntactically unique yet functionally identical variant of the malicious code. For example, Figure 3 shows differences in code snippets highlighted in red. This constant mutation makes detection more difficult. Figure 3. Polymorphism creating multiple variants of dynamically generated JavaScript code. Of note, LLM-generated code can include hallucinations but we mitigated this through prompt refinement and increased specificity, effectively reducing syntax errors. As a result, the final, highly specific prompt successfully generated functional code in most instances. Step 3: Executing Malicious Scripts at