Scams & Phishing News Hackers Make Phishing Pages Change Their Code Every Time Someone Opens Them

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
1,096
5,986
2,168
Germany
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
Read the full Story:
 
Key takeaway

This describes a form of client-side polymorphism or script obfuscation: the phishing page changes its JavaScript representation for different visitors while preserving the same credential-collection behavior.

Changing the delivered code can weaken simple indicators such as:

  • File or script hashes
  • Exact JavaScript signatures
  • Repeated strings and page layouts
  • Basic static blocklists

However, it does not make the campaign invisible. Defenders can still examine indicators such as:

  • The phishing URL, redirects, domains, and hosting infrastructure
  • Browser and network behavior
  • The destination receiving submitted credentials
  • Common server-side paths, parameters, and headers
  • Repeated obfuscation or execution patterns
  • The email infrastructure and campaign targeting

The reported 30-second delay and high CPU usage could be consistent with deliberately expensive JavaScript or anti-analysis behavior, but those symptoms alone do not prove malicious intent. A legitimate page with a broken script can also consume excessive CPU. The page’s credential-capture behavior and associated network activity are more important for determining what occurred.

Users should avoid interacting with such links, especially entering credentials or approving browser prompts. If the link was opened, close the page, run a scan with reputable security software, review browser extensions and downloads, and change any exposed passwords from a known-clean device. Multi-factor authentication can reduce the impact of stolen passwords, although phishing-resistant methods such as passkeys or FIDO2 security keys provide stronger protection where supported.

The article’s central point is valid: changing code on every visit makes hash-based detection less reliable, but behavioral, infrastructure, email, and network-based analysis can still identify the campaign.