PhaaS: The threat that keeps hitting inboxes

A case study for needing threat intelligence indicator democratisation

Note: The activity found in this blog post is from a security investigation where the threat actor failed. There are additional tools, techniques and procedures (TTPs) as well as indicators of compromise which can be shared privately from my work tracking this threat. This private research will be presented at Detect London 2025.

Introduction

Phishing-as-a-Service (PhaaS) has increased in popularity and in volume between 2023 and 2024. I recently observed a phishing campaign which was huge in size and resources. After some initial triage, it is clear multiple threat actors are utilising Phishing-as-a-Service providers to conduct initial access or business email compromise (BEC) operations on organisations worldwide. The scale of this activity is vast. In October 2023, Microsoft stated that one of these threat actors, STORM-1575, was responsible for the highest phishing volumes from activity they track.¹

Phishing providers have started to increase their capabilities making detection and mitigation of this threat more difficult. For example, the polymorphic nature of their response pages and regular domain rotation in the phishing chain. Some indicators may be altered or details may be removed to protect my intelligence collection process.

This blog posts aim is to help defenders hunt and identify initial characterstics of PhaaS activity in their estate, with indicators of compromise to aid in this effort. There are many other blog posts referenced which detail in depth multiple PhaaS frameworks internals.

Analysis

My investigation started with a phishing link which exploited an open redirect vulnerability on a popular search engine. The open redirect was likely used by the threat actor to avoid spam filters and security technologies.

There were several redirects in place if the user clicks the link:

• Initial link which contained an open redirect vulnerability;

• href.li link redirecting to the next stage;

• Cloudfront page redirecting to a AWS S3 bucket;

• S3 bucket HTML phishing page; and,

• Threat actor infrastructure.

The threat actor abused many cloud services during this campaign such as Cloudflare (Captcha), Google (Captcha), AWS (Cloudfront and S3). The dynamic nature of cloud services and our increasing reliance on them makes detection harder for researchers and SOCs. For example, S3 is used regularly for static resources across the internet. A capture of the S3 hosted phishing page can be found in Figure 1 which is unlikely to be blocked by security technologies.

Figure 1 - Initial phishing landing page

The phishing page utilised HTML smuggling by dynamically creating an iframe from a base64 encoded URL as shown in Figure 2. HTML smuggling isn’t anything new² and is popular for phishing threat actors to evade detection for their final payload. PhaaS providers have made HTML smuggling increasingly complex, utilising AES encryption, XOR and base64 decoding to transform sets of data.

Figure 2 - HTML smuggling iframe

The phishing page has anti-debugging measures in place and fingerprints every request it receives, as shown in Figure 3. The phishing page will continually launch the debugger command to make analysis from web developers tools much harder. A form is self submitted containing information on your browser client including your IP, referer user agent and generated SID (these have been intentionally removed for this blog post).

Figure 3 - Phishing anti-debugging and fingerprinting

When requesting for the page as shown in Figure 3 I can see many different comments have been generated alongside the code. This is likely to alter the content response making it harder to track for researchers. This is displayed by a short Python terminal session below:

>>> import requests
>>> import hashlib
>>> req = requests.get("<malicious url>")
>>> hashlib.sha256((req.text).encode()).hexdigest()
'746962b4926ef173362fc7d54c17d56c67d9f980da2e6e637647ce2f2809ee30'
>>> req = requests.get("< same malicious url>")
>>> hashlib.sha256((req.text).encode()).hexdigest()
'3298bd66b699a30d707f74f57276a0554cada244fa3fc9a6633b2242d35a3f39'

The phishing page initial loading is multi-staged and similar to what other researchers have identified throughout 2024.³ The similarities being:

• Use of href.li for redirection into main phishing resources;

• Use of Cloudflares CryptoJS Library;

• Use of Cloudflare or Googles Captcha to make sandbox analysis harder; and,

• Use of AES to decrypt phishing payloads.

Not only have these providers found suitable ways to make detection harder for researchers but have also developed a capability to utilise multi-factor authentication. Multi-factor authentication has been an important mitigation⁴ against phishing but threat actors have recently innovated, relaying multi-factor authentication details along the authentication process.⁵ Multi-factor controls are not enough to protect against modern phishing attacks. Organisations should be actively threat hunting and identifying risky users in their organisations.

Uptick or more data needed?

While researching about PhaaS, I was impressed by how quickly domains are rotated, the different vectors that were used by the threat actor and how quickly the attack was executed. The vast scale gave me an indication that they had considerable financial resources to perform this. I have been tracking a cluster of PhaaS activity and can identify almost 4,000 domains which have been registered and intended for phishing infrastructure in 2024. The graph indicates an uptick of domain registrations in the latter half of 2024 as shown in Figure 4.

Figure 4 - Phishing domain registrations dates graphed

Conclusion

Through pivoting and research, I have identified almost 4000 domains associated with phishing as a service (PhaaS). While some of the domains were clearly designated as malicious by threat intelligence providers, a worrying percentage were not. Open source research (blogs or conference talks) on this threat has limited indicators for threat intelligence consumers to query over. This threat isn’t as sophisticated as other threats posed to organisations, yet indicators are barely shared or consumed at the rate the threat actor is rotating their domains and infrastructure.

This threat is a clear example of threat intelligence needing better democratisation of indicators. The purpose of this publication is exactly that, to give all organisations a vast quantity of indicators to query over and protect themselves in a clear and open manner. These indicators should not be sensitive, the techniques in how they are acquired should be. Indicators decay in quality and on this occassion are granular, they are domains with limited properties. As defenders, we should work harder in better sharing processes or improving existing ones like MISP, not enough Threat Intelligence producers I fear are working to do so.

Organisations in the legal, technology, financial, governmental, energy, consulting and educational sectors were identified when conducting this research.

Indicators of Compromise (IoCs)

I understand everyone consumes Threat Intelligence differently via unstructured and structured processes. I have attempted to make these IoCs as accessible as possible. I have decided that raw new line delimitations for indicators is the most flexible format for indicators which can be found here where I have published over 3,900+ domains related to phishing as a service (PhaaS) activity. The full URL:

https://github.com/ext-jack/threatintel/blob/main/phishing_research_phaas_2024

MITRE ATT&CK

T1566

Phishing

The activity outlined in this blog post show tools, techniques and procedures from a phishing threat actor which has targeted a variety of organisations.

T1583.001

Acquire Infrastructure: Domains

The threat actor has registered nearly over 4,000 domains in under a year to conduct phishing as a service activities (PhaaS)

1. https://x.com/MsftSecIntel/status/1712936244987019704?lang=en

2. https://www.huntress.com/blog/smugglers-gambit-uncovering-html-smuggling-adversary-in-the-middle-tradecraft

3. https://blog.nviso.eu/2024/10/02/all-that-javascript-for-spear-phishing/

4. https://www.ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa

5. https://blog.sekoia.io/tycoon-2fa-an-in-depth-analysis-of-the-latest-version-of-the-aitm-phishing-kit/