How the static site trend has affected phishing

The trend towards statically generated websites hasn't been limited to legitimate websites. Increasingly, you'll see phishing sites hosted on static hosts like GitHub Pages, IPFS (via gateways), and even S3 buckets.

But this is a very different environment to the VPS providers that phishing sites have been using for years, and so the phishing kits have had to adapt.

The de-PHPification of phishing kits

Hosting providers

A big benefit of static sites is the ease of deployment. There's no need for any server-side processing so if you can upload HTML to it, you can host a site on it.

This has massively increased the number of places phishers can host their sites. From no-code app builders, to S3 buckets, any new service will quickly find themselves abused to host phishing.

In fact, you don't even need a service to abuse, you can even send a static phishing site as an email attachment.

Anti-analysis checks

Many phishing kits employ at least some basic cloaking or anti-analysis checks to make it harder for automated scanners to access them:

• Is the connection coming from a residential IP address? From the expected country?
• Is the user-agent a mobile device? (because why would a phishing site distributed by SMS be opened on desktop?)
• Does the URL contain a specific query parameter? (i.e. are you actually following the phishing link or did you just stumble upon the domain)

While simple, these checks can be very frustrating for a security team. You know this site is malicious, but you can't convince the hosting provider of this because they can't get the phishing page to load.

With a PHP-based phishing kit, these anti-analysis checks are done server side so the exact logic is unknown to the security team (unless they've managed to obtain a copy of the phishing kit). But with static phishing sites, the anti-analysis code is plain to see!

if (navigator.webdriver) {
    window.location.href = 'https://google.com';
}
var ua = window.navigator.userAgent;
var expectedUA = 'Mozilla/5.0 (iPhone; CPU iPhone OS 13_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Mobile/15E148 Safari/604.1';
if (ua !== expectedUA) {
    window.location.href = 'https://www.google.com';
}

If this sort of logic was on the backend we'd be stuck trying to guess the corrent user agent, but here we immediately know what to use.

Or, if the checks are really that onerous to work around, we can just comment them out and continue analysing what the site does.

Log collection

The point of a phishing site is to log credentials and classic kits did this in two main ways:

• Writing collected credentials to a text file on the web server
• Emailing credentials to the phisher

Neither of these methods are compatible with static hosts.

Instead, static phishing sites have to rely on other ways to log credentials:

• Using an API (like a Telegram bot or Discord webhook) to post credentials to a messaging platform.
• Using a SaaS that takes HTML form submissions and emails you the result.

Are these static phishing sites more or less of a problem?

The ease at which static phishing sites can be deployed means they often get stood back up faster after they're taken down. And, because there's no server-side component, there's very rarely any vulnerabilities that can be exploited.

But, the entirety of a static phishing kit's code is easily accessible to security teams and so:

• They're easier to analyse (everything the site does is clear to see)
• They're much easier to write detection rules for (how often do legitimate sites call out to an IP reputation providers and then redirect to another domain?)
• They're easier to attribute (you can see exactly where the credentials are being sent and hence whether this is the same threat actor you've seen before)