A newly analyzed phishing operation is using server-side polymorphism to generate a distinct credential-harvesting page for virtually every request, undermining detection approaches built around file hashes, fixed HTML identifiers, and static JavaScript signatures.
The campaign came to light after a phishing message submitted to the SANS Internet Storm Center (ISC) pointed recipients to a URL structured as hxxps://addresses[.]performs[.]vu/communications.html?good=[recipient_address].
At first glance, the lure appeared routine. The target, however, served heavily obfuscated JavaScript that behaved differently across visits, eventually revealing a credential-stealing page whose underlying source code changed on every load.
The first visit did not render a phishing form at all. Instead, the browser stalled for roughly 30 seconds while a single CPU core reached 100% utilization, suggesting that the problem was client-side rather than caused by slow server response.
Analysis identified a logic error in the JavaScript decoder. Two functions relied on the same undeclared loop variable, k, making it global rather than local.
The outer routine was intended to iterate through values 0 to 63 as it built a decoding map. During each pass, it invoked a helper function that generated character strings for a Base64 alphabet.
A final helper call reset the global counter to 48. The outer loop then incremented it to 49, only for the inner routine to reset it again.
The decoder consequently became trapped in a repeating 48 → 49 sequence, preventing the browser from completing rendering while continuously consuming CPU resources.
Correcting the variable-scope collision allowed the payload to decode, exposing an otherwise conventional credential-stealing form.
The broken response initially looked like a simple coding mistake. Subsequent requests showed otherwise: the same URL later loaded normally, but each response carried a different implementation of the phishing page.
Across repeated loads, researchers observed randomized function and variable names, reordered functions, numerals represented through different arithmetic expressions, and altered encoded JavaScript blocks containing the final phishing payload.
The page title also rotated between innocuous terms including “Solution,” “Viewer,” “Credentials,” “Private,” and “Authenticate.”
A test involving 50 downloads of the same URL produced 50 samples with distinct SHA-256 hashes. The collection included 21 unique page titles.
Forty-nine samples deobfuscated successfully, while one reproduced the infinite-loop condition caused by another randomized variable-name collision.
Polymorphic Phishing Attack
SANS Researchers said that, polymorphism continued after JavaScript decoding. Each resulting phishing page used different form-field names, HTML element IDs, CSS class names, image-loading parameters, and zero-width-character placements.
Despite those source-level changes, the victim-facing form and credential-theft workflow remained substantially the same.
The technique is designed to degrade the value of conventional indicators.
A URL reputation system may still flag the infrastructure, but a detector relying on a single malicious hash, a particular input-field identifier, or a fixed JavaScript string can fail when each request produces a syntactically new sample.
Zscaler previously documented kits that create randomly named files and directories, along with random HTML attribute values, per visit to complicate analysis and signature-based detection.
However, this case demonstrates that aggressive mutation can introduce operational risk for attackers. Of approximately 56 collected samples, two were non-functional, indicating that the polymorphic generator occasionally produces pages unable to complete their own decoding routine.
That failure rate cannot establish the campaign’s overall reliability, but it shows that evasive code generation can degrade the attacker’s credential-harvesting success.
The campaign’s per-request generation raises an obvious question: whether an LLM was involved. There is no evidence proving that it was.
The systematic transformations and repeated variable-scope defects instead point more plausibly to a conventional polymorphic obfuscator that renames and reorders code without correctly accounting for JavaScript scope.
The possibility is nevertheless relevant. Unit 42 has demonstrated a proof of concept in which a webpage calls trusted LLM services to generate malicious JavaScript dynamically in the victim’s browser.
That model can create a syntactically distinct phishing payload per visit and reduce the effectiveness of static and network-only inspection.
For defenders, the practical lesson is to prioritize behavioral and runtime signals: suspicious form submission destinations, browser-side deobfuscation activity, excessive CPU consumption, dynamically generated DOM content, and credential capture attempts.
Polymorphism may frustrate static signatures, but it does not change the page’s ultimate behavior collecting and exfiltrating credentials.
★ Which Security Tools Should You Cut? Score Them on One Page – Download the Inherited Security Stack Guide
