Today, phishing accounts for the majority of all cyberattacks. The availability of low-cost, easy-to-use Phishing-as-a-Service (PhaaS) platforms like Tycoon2FA, EvilProxy, and Sneaky2FA only makes the problem worse.

These services are actively maintained by their operators; new evasion techniques are regularly added, and the multi-layered infrastructure behind the phishing kits continues to evolve and expand.

But beyond these established players in the PhaaS market, the ANY.RUN team sometimes comes across phishing campaigns that use tools unlike anything we’ve seen before.

One such example is a framework we’ve dubbed Salty 2FA, whose execution chain and infrastructure have not previously been documented.

Like other PhaaS platforms, Salty 2FA is mainly delivered via email and focuses on stealing Microsoft 365 credentials. It unfolds in multiple stages and includes several mechanisms designed to hinder detection and analysis.

Let’s dive deeper into how Salty 2FA works.

Key Takeaways

Salty 2FA is a newly discovered PhaaS framework, with overlaps to Storm-1575/1747 but distinct enough to stand apart.

It uses a unique domain pattern (.com subdomains paired with .ru domains) and unfolds in a multi-stage execution chain designed to resist detection.

The kit can bypass multiple 2FA methods (push, SMS, voice), giving attackers access beyond stolen credentials.

Victims span global industries including finance, telecom, energy, consulting, logistics, and education.

Static IOCs are unreliable; detection requires spotting behavioral patterns that persist across samples.

ANY.RUN’s interactive sandbox was essential in mapping its execution flow and exposing its infrastructure in real time.

Discovery of Salty 2FA

During phishing campaign hunting, several ANY.RUN sandbox sessions were identified that had not yet been flagged as malicious. At first glance, they showed familiar traits: Cloudflare Turnstile, a fake Microsoft login page, and unknown domains.

Check analysis sessions:

Analysis session 1

Analysis session 2

*Analysis of the phishkit inside ANY.RUN’s Interactive Sandbox*

What stood out in these cases was the domain infrastructure. In the IOCs section of the sessions, a pattern became clear: the consistent use of compound domains in “.com” zones (e.g., .com.de, .it.com) in combination with domains registered under the .ru TLD. The phishing pages themselves also followed a recurring format, embedding “.com” subdomains within a pattern of

The URI paths hosting the phishing content also appeared unusual. While they initially looked randomly generated and unrelated, further inspection suggested they might share commonalities worth examining.

With this hypothesis in mind, a query was run in Threat Intelligence Lookup:

domainName:”*.*.??.com$” AND domainName:”.ru$”

The results confirmed that this domain pairing is indeed a recurring element tied to phishing activity. Moreover, it highlighted that this indicator had not yet been fully integrated into the detection system, leaving a potential coverage gap.

*Hypothesis validation in ANY.RUN’s TI Lookup*

The initial results left some uncertainty. In addition to the incomplete detection coverage at the time of analysis, the sample included tasks with potential true negative verdicts, as well as tasks tagged under different categories. These ranged from generic phishing labels to Tycoon and EvilProxy; campaigns that had not previously demonstrated the observed behavior (the .??.com + .ru domain combination).

To reduce ambiguity, the query was refined with contextual filters, focusing on specific resources such as requests to Cloudflare.

The updated TI query produced much clearer results, confirming that this activity is almost certainly tied to a distinct phishing operation. However, it cannot yet be definitively attributed to any of the known actors.

Refined TI query:

domainName:”*.*.??.com$” AND domainName:”a.nel.cloudflare.com” AND domainName:”challenges.cloudflare.com” AND NOT domainName:”cdnjs.cloudflare.com” AND domainName:”.ru$”

After a quick review of the external indicators, the next step was to examine the client-side code used in this phishing campaign to better understand its functionality and capabilities.

Technical Deep Dive: Execution Chain

To capture decrypted traffic and analyze the payload step by step, a similar session was rerun with the MITM proxy enabled.

Check analysis session with MITM enabled

*Analysis of a phishing page inside ANY.RUN’s Interactive Sandbox*

When the page loads from parochially[.]frankfurtwebs[.]com[.]de, a small “trampoline” JavaScript executes. It initializes the Cloudflare Turnstile widget, runs the associated checks, and returns a cf_response token. After that validation, the server delivers the HTML that initiates the main execution chain.

Stage 1: Obfuscated Entry Script

The source code contains comment inserts with inspiring quotes. These do not affect functionality but act as filler “noise,” making static analysis more challenging.

A small JavaScript snippet contains an obfuscated function designed to decode the address of the next stage, retrieve it, decode it in the same way, and then write the result into the DOM of the current page.

Decoding the value lPwICAQHzsPDAfUG//kIBAD19/nGyPn9wgYJw8M= reveals the URL of the next payload:
hxxps[://]marketplace24ei[.]ru//

Stage 2: Encrypted Payload and Fake Login Page

After loading and decoding the payload, the result is a large HTML page—again padded with non-functional “noise” just like the previous stage—with an obfuscated JavaScript snippet at the end.

A quick search through the HTML for tags revealed several matches. One stood out:

Decoding the Base64 value exposes another URL that becomes relevant later:

hxxps[://]marketplace24ei[.]ru/790628[.]php

Comparing the HTML source to the session’s runtime behavior also shows that the attacker obfuscates the page text itself. For example, the string:

“Because you’re accessing sensitive info, you need to verify your password.”

appears obfuscated in the code rather than in plain text.

*Source code of the fake Microsoft login page*

Stage 3: Client-Side Logic and Anti-Analysis Mechanisms

All of the logic for switching between page states, as well as the collection and exfiltration of user input, is handled by the previously mentioned JavaScript code.

After deobfuscating this script, we can walk through its key technical details and capabilities.

To begin with, nearly all of the front-end logic relies on calls to page elements through jQuery. The identifiers for these elements are generated dynamically, making analysis more difficult. In addition, the element IDs themselves are encoded using a combination of Base64 and XOR with a fixed generated value, which must be decoded through a dedicated routine.

*Procedure for decoding page element IDs*

Managing web page elements with jQuery (decoded values)

The phishing payload also includes several basic defense mechanisms commonly seen in such campaigns:

Blocking keyboard shortcuts that open debugging tools (e.g., DevTools).

Measuring execution time when a debugger is triggered and halting further activity if a delay is detected, which may indicate the code is running in a controlled or lab environment.

For exfiltration of the victim’s input, the data is “encrypted” using the same Base64 + XOR technique. This time, however, the key parameter is derived from the victim’s session identifier.

Stage 4: Data Exfiltration and Server Interaction

The stolen data is sent to servers using .ru domains from the observed cluster, with endpoints following the format:

/<5-6_digits>.php

The data itself is encoded and placed in the request= parameter of the POST request, while the decoding key (along with the victim’s session ID) is stored in the session= parameter.

*Encoding procedure for exfiltrated data using the session key*

Using a POST request captured in the session as an example, the data can be examined by applying the same encoding routine in reverse:

Utilize the following CyberChef recipe to decode the data: https://gchq.github.io/CyberChef/#recipe=URL_Decode(true)From_Base64(%27A-Za-z0-9%2B/%3D%27,true,false)XOR(%7B%27option%27:%27UTF8%27,%27string%27:%27b17be01b20c089141058415728fd66ff%27%7D,%27Standard%27,false)&input=R1JOWUVrY0tFeFpBUlFZU0ZCdFVXUk1LRjFWZFdsQjNVMW9GU2xWWkMwUWY&oeol=VT

Stage 5: Multi-State 2FA Handling

In response to the POST request, the server returns a JSON object. The value of the response field depends on the current state of the phishing page; that is, on which opcode was specified when the data was submitted.

Analysis of the code revealed several possible states of the phishing page, along with the data structures transmitted to the attacker as the page transitions between these states.

The identified states are as follows:

State #	State Name	Function	Trigger	Data Sent (decoded)	Data Received (decoded)
1	Initial state	Prompts victim to enter email	When the phishing login page first loads	n/a	n/a
2	Switch to password page state	Prompts for password	When the victim enters a valid email	{"op":"true","em":	{"status":
3	Switch to “Stay signed in” state	Prompts “Stay signed in?”	When the victim enters a valid password	{"op":"bk"}	n/a
4	Switch to “Incorrect password” state	Prompts “Account locked / incorrect password”	When the victim enters an empty or invalid password	n/a	n/a
5	Switch to “2FA” state	Initiates 2FA handling	When the victim’s account has 2FA enabled	{"op":"ne","em":	{"status":
6	Switch to “Process 2FA method” state	Processes the chosen 2FA method	After state #5	{"m":	{"status":
6.1	Phone App Notification 2FA	Handles phone app push notifications	After state #6	{"op":"Vx","token":	{"status":
6.2	Phone App OTP 2FA	Handles OTP from phone app	After state #6	{"op":"Vx","token":	{"status":
6.3	OneWaySMS 2FA	Handles one-way SMS OTP	After state #6	{"op":"Vx","token":	{"status":
6.4	TwoWayVoiceMobile 2FA	Handles mobile voice call 2FA	After state #6	{"op":"Vx","token":	{"status":
6.5	TwoWayVoiceOffice 2FA	Handles office phone voice call 2FA	After state #6	{"op":"Vx","token":	{"status":
6.6	Companion Apps Notification 2FA	Handles companion app push notifications	After state #6	{"op":"Vx","token":	{"status":

*Code snippet handling the 2FA authentication method*

Capabilities and Evasion Techniques

Based on the complexity of its infrastructure, such as the use of multiple domains across specific TLDs, including a dedicated domain for data exfiltration, the presence of evasion techniques, and its extensive functionality (credential validation, handling multiple 2FA methods, and intercepting OTP codes), this campaign appears to represent a new PhaaS framework. Its behavioral patterns differ from those of the major players in the phishing ecosystem, such as Tycoon, EvilProxy, and others.

Is it Storm-1575 or Storm-1747?

At the time of initial research, no clear evidence was found to indicate who operates or develops this phishing kit, how the attackers obtain access (e.g., whether they purchase software), or any distinctive technical traits that would link it to other known kits.

After updating detection methods and re-hunting indicators in the ANY.RUN Sandbox and TI, some overlap in IOCs (specifically domains) emerged with activity tracked as Storm-1575 and Storm-1747.

Storm-1575 is associated with the PhaaS platform Dadsec and is presumed to be its developer. However, Dadsec activity has not been observed recently, and attribution boundaries for Storm-1575 remain unclear.

Storm-1747, on the other hand, is well known for Tycoon 2FA—a state-of-the-art phishing kit that has ranked among the most active in terms of both attacks and related samples for several years. That said, Tycoon relies on a different infrastructure (mainly es-ru-es domain chains) and implements distinct client-side code, including its obfuscation and exfiltration techniques.

To track and assess this phishing activity, the framework was designated Salty 2FA, a name inspired by its “salted” payloads, which consistently helped distinguish its code from other kits during analysis. More importantly, a unique threat name was required, one easier to work with than YetAnotherPhishkitActivity2FA, and “Salty 2FA” struck the right balance of clarity and memorability.

Check potential overlaps between Salty 2FA and Storm-1575/1747

Salty 2FA Targets and Activity Timeline

Analysis of phishing emails, their content themes, and pre-filled victim email addresses (automatically inserted via the #email anchor in URLs) made it possible to identify the targets of this campaign, including affected countries and industries.

Observed targets include:

Country / Region of the Organization	Industry
USA / Worldwide (India)	Metallurgy
USA / LATAM	Financial
Greece	Telecom
Germany / Worldwide	Chemicals / Polymers
Spain	Energy (solar panels)
Spain	Energy
USA	Real estate development
Switzerland / Worldwide	Logistics
USA	Healthcare
USA	Financial
USA	IT consulting / Staffing
USA	Environmental services
Canada / France	IT
USA	Government
UK / Worldwide	Consulting / Financial
Italy	Industrial (packaging, automation)
UK	Construction / Infrastructure
USA / Worldwide	Logistics
USA / Worldwide	Logistics
USA	Oil and gas
USA	Financial / Insurance
UK	Real estate
USA	Chemicals / Packaging
USA	Consulting / Financial
USA	Data management / Storage
USA	Automotive accessories
USA	Construction / Contractors
USA	Education
USA	Financial

Common phishing email lures included:

“Voice message was left…”

“Access full document…”

“Payroll amendment…”

“Request for Proposal…”

“Bid invitation…”

“Billing Statement…”

Additional IOCs extracted from SPF records in email headers:

153[.]127[.]234[.]4

51[.]89[.]33[.]171

191[.]96[.]207[.]129

153[.]127[.]234[.]5

izumi[@]yurikamome[.]com

Activity timeline:

Based on data from the ANY.RUN Sandbox and TI, activity resembling Salty 2FA began gaining momentum in June 2025, although it is possible that early or “raw” variants of the kit, or samples similar to it, were already being deployed as early as March–April 2025.

Confirmed activity attributed to Salty 2FA has been observed since late July 2025 and continues to this day, generating dozens of new public analysis sessions in the Sandbox every day.

How to Spot Salty 2FA

Basic indicators such as domain names (hashes are not applicable here due to constant obfuscation and code mutation) can be useful for threat hunting and expanding the threat landscape. In some cases, they may even lead to detections. However, for phishing kits like Salty 2FA, these indicators are generally unreliable for long-term or consistent detection.

Threat detection specialists and engineers instead need to identify behavioral patterns that remain consistent across samples, even when those samples appear completely different at first glance.

Any recurring clue, whether it is a particular chain of TLD zones in domain names, distinctive URL structures, unusual web page headers, or a characteristic set of resources loaded from legitimate CDNs, contributes to the behavioral profile of a PhaaS framework. These recurring traits allow analysts to track and detect it over time without relying on volatile details such as email hashes or specific phishing domains.

Detect and Distinguish Similar Emerging Threats in Seconds

With solutions like ANY.RUN‘s Interactive Sandbox, analysts can observe phishing kits in real time, uncover hidden behaviors, and distinguish between similar frameworks. By focusing on behavioral patterns rather than fragile indicators, it becomes possible to track evolving PhaaS activity more reliably, while also enjoying a smoother, less resource-heavy investigation process.

Real-time visibility into phishing execution chains and payload delivery.

IOC enrichment with domains, infrastructure elements, and threat behavior insights linked to wider campaigns.

Faster investigations with reduced manual workload and clearer insights.

Seamless collaboration between analysts through shared interactive sessions.

Conclusion

The ecosystem of Phishing-as-a-Service (PhaaS) platforms is constantly evolving. Existing kits adapt their attack methods, while new players emerge, some entirely brand-new, others reimagined versions of tools once used by well-known threat actors.

The analyzed framework, Salty 2FA, shares certain traits with Storm-1575, the group behind the Dadsec platform. However, a deeper examination revealed too many unique characteristics to reliably attribute it to any of the known threats, such as Tycoon2FA, Sneaky2FA, Mamba2FA, Gabagool, or EvilProxy.

With its ability to distribute phishing payloads at scale, maintain dynamic infrastructure, intercept and process most known 2FA authentication methods beyond simple credentials, and manage a complex communication model between phishing pages and C2 servers, Salty 2FA stands on par with the “major” kits in today’s phishing landscape.

For SOC teams triaging phishing-related incidents, it is critical to quickly and accurately confirm the malicious nature of collected artifacts and correlate them with the threat actor likely to be targeting their organization.

ANY.RUN’s Interactive Sandbox enables security professionals worldwide to detect and analyze threats like Salty 2FA by replicating victim interactions and tracking execution chains in real time, while leveraging behavior-based detection to expose previously unknown samples and indicators.

Try It Yourself

See how Salty 2FA and other emerging phishing kits unfold in real time. ANY.RUN’s Interactive Sandbox lets you safely detonate samples, follow execution chains, and uncover hidden IOCs in seconds.

Request 14-day trial for your SOC →