Hackers are making some phishing pages harder to track by changing the code delivered to every visitor. An examined operation served a credential-stealing form whose appearance stayed familiar while its structure kept shifting.
The attack started with a phishing message containing a web link. Opening it did not show a login page in one case; instead, the browser stalled for roughly 30 seconds and drove one processor core to use, suggesting the problem sat inside the page rather than on the hosting server.
Analysts at the Internet Storm Center identified the unusual behavior while reviewing a message sent to their handler inbox.
Internet Storm Center said in a report shared with Cyber Security News (CSN) that the suspicious page used heavily scrambled JavaScript and ultimately revealed a conventional form designed to collect credentials.
The finding matters because many defenses benefit from stable clues, such as a file hash, a repeated page field, or a recognizable string in a script. When each visit receives a fresh version, those clues lose value, even though the page still performs the same harmful task.
Hackers Make Phishing Pages Change Their Code
The researchers returned to the same address and found that later requests loaded normally. They then fetched it 50 times: every sample had a different SHA-256 hash, 21 separate page titles appeared, and the code rearranged functions, renamed variables, and rewrote numeric values through different calculations.
The changes reached beyond the first JavaScript layer. After decoding, all 50 final HTML pages were also different, with altered form and input names, CSS classes, page element identifiers, image parameters, and hidden zero-width characters placed inside visible text.
.webp)
To a visitor, however, the result looked and worked much the same: a page intended to obtain login details.
That disconnect is the point of polymorphism, a technique that makes the source look new without changing its purpose, and it complicates the kind of static matching used to catch repeat phishing infrastructure. The approach does not make detection impossible.
Security teams can still study page behavior, form submission paths, hosting patterns, and structural features that persist beneath the changing code, much as coverage of Unicode-hidden JavaScript phishing lures has highlighted the limits of relying on a simple file signature alone.
A Coding Error Exposed the Scheme
The first sample failed because two decoding loops used the same undeclared variable, k. An inner helper routine repeatedly reset the counter used by the outer loop, trapping it between values 48 and 49 and leaving the browser busy rather than allowing the malicious page to finish loading.
After the analyst gave the inner routine its own local counter, the decoder completed and the credential form emerged. One of the 50 scripted downloads repeated the same flaw, while 49 decoded successfully, indicating that the faulty version was not merely a damaged response during delivery.
Across about 56 samples, including the original manual checks, two pages failed. That is not enough to calculate a dependable failure rate, but it shows the code-generation process can undermine its operators as well as frustrate analysts and automated scanning systems.
The report does not establish that artificial intelligence generated the variants. It notes that real-time LLM-written phishing code is possible, but the systematic changes and recurring variable-scope mistake more strongly fit a conventional obfuscation tool that randomizes names and code order without properly handling scope.
For defenders, the practical lesson is to avoid treating a clean-looking page or a changed hash as proof of safety.
Email filtering should be paired with URL analysis and behavior-based inspection, while employees should verify unexpected sign-in prompts through a known route instead of a message link, especially as email phishing threats climbed sharply.
Organizations should also prepare for account compromise rather than assuming a password reset ends the risk.
Where a phishing operation steals authenticated sessions, defenders may need to revoke active sessions and tokens, review access activity, and audit suspicious identity changes promptly across affected accounts, as seen in multi-factor session theft campaigns.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| Domain | addresses[.]performs[.]vu | Domain hosting the polymorphic phishing page |
| URL | hxxps[:]//addresses[.]performs[.]vu/communications.html?good=[ | Phishing link observed in the analyzed message |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC
