Phishing toolkits are usually easy to identify. Each one tends to leave behind its own fingerprints whether in how emails are delivered, how infrastructure is set up, or how the client side code behaves. Because of this, attributing an attack to a specific kit has traditionally been fairly straightforward.
That pattern is now starting to break.
Recent phishing samples have surfaced that don’t fit neatly into a single category. Instead, they display characteristics from multiple phishing frameworks at the same time. Analysts at ANY.RUN observed this unusual behavior while tracking Salty2FA and Tycoon2FA. What began as a noticeable decline in Salty2FA activity soon turned into something more concerning: Tycoon2FA indicators started appearing within attack chains previously linked to Salty2FA, and eventually, individual payloads were found carrying code from both toolkits.
This convergence represents a significant shift in the phishing landscape. It weakens detection rules built around specific kits, makes attribution more difficult, and gives attackers greater flexibility to evade early security controls.
Below is a closer look at how this hybrid threat developed, why it matters for the future of 2FA phishing, and what defenders should consider moving forward.
Key Takeaways
-
Salty2FA activity dropped sharply in late October 2025, falling from hundreds of weekly submissions in ANY.RUN’s Interactive Sandbox to only a few dozen.
-
New phishing samples began showing shared indicators from both Salty2FA and Tycoon2FA, including overlapping IOCs, tactics, techniques, and procedures, as well as triggering detection rules associated with both kits.
-
Code analysis confirmed the presence of hybrid payloads: initial stages closely resembled Salty2FA, while later stages mirrored Tycoon2FA’s execution flow almost exactly.
-
Parts of Salty2FA’s infrastructure appeared to fail, forcing campaigns to rely on Tycoon2FA-based hosting and payload delivery mechanisms.
-
This overlap aligns with earlier theories suggesting a possible link to Storm-1747, a threat actor group commonly associated with Tycoon2FA operations.
-
Accurate attribution remains critical, as distinguishing between different 2FA phishing kits helps analysts refine hunting strategies and track attacker behavior over time.
-
Detection logic should be updated to handle scenarios where Salty2FA and Tycoon2FA coexist within the same campaign or even within a single payload.
-
Further cross-kit blending is likely, signaling that future phishing campaigns may increasingly mix infrastructures, payloads, and attack techniques across frameworks.
Part 1: The Numbers Tell the Story Salty2FA’s Sudden Decline
The shift first became apparent toward the end of October 2025. At that time, the number of ANY.RUN sandbox submissions associated with Salty2FA dropped sharply compared to historical levels.
Weekly phishing summaries showed that, despite normal fluctuations in total upload volume, Salty2FA had consistently appeared in several hundred analysis sessions per week. That stability vanished almost overnight.
By early November, the decline accelerated. On November 11, 2025, Salty2FA fell to the bottom of the weekly threat rankings, with just 51 submissions far below its usual average of more than 250 per week. This sudden collapse set the stage for the hybrid behavior that followed.
Alongside indicators of compromise and threat-hunting rules, ANY.RUN’s sandbox network layer had consistently flagged near constant alerts linked to Salty-specific HTTP traffic.
This behavior was tied to the Suricata detection rule sid:85002719. When analysts filtered public submissions to identify analysis sessions where this rule had triggered, the latest hit was dated November 1, 2025.
At first glance, the explanation seemed straightforward: the detection logic may have fallen out of date, the phishing framework could have been updated, and the signatures simply hadn’t been refreshed yet. However, that raised a follow-up question what about infrastructure-based indicators, such as domains and hosting patterns?
Although indicators of compromise rank lower on the Pyramid of Pain than tool or TTP based detections, they remain valuable for large-scale tracking. Domains and network artifacts often persist long enough to provide consistent visibility across campaigns, leaving repeated traces that analysts can follow over time. These recurring indicators help maintain context around a threat and support broader hunting efforts to uncover related infrastructure, behaviors, and operational patterns.
With that in mind, the next step was clear: identify recent analysis sessions labeled with the threat in ANY.RUN’s Threat Intelligence Lookup, review any changes in client-side code and overall kit behavior, and then adjust detection logic accordingly. The initial query used for this investigation was:
threatName:"salty2fa"
In one case, analysts observed an analysis session leveraging an ASP.NET-based CDN, a setup that does not align with Salty2FA’s typical infrastructure. It began to appear as though a switch had been flipped, abruptly taking a large portion of the framework’s backend offline.
At first, this raised the possibility of a shutdown—but the reality proved to be more complex.
As Salty2FA activity declined, analysts started encountering an increasing number of sessions where the final verdict pointed to both Salty2FA and Tycoon2FA. While the two phishing kits offer comparable functionality, they differ significantly in architecture, infrastructure management, and operational patterns.
This overlap did not look like a simple attribution error. The presence of Tycoon2FA was reinforced by well-established detection logic, including rules designed to identify DGA-generated domains associated with Tycoon2FA’s fast-flux infrastructure.
Check analysis session showing both Salty2FA and Tycoon2FA
This led to another working theory: the operators behind these phishing as a service platforms may have begun sharing or outright merging their infrastructure. To test this idea, analysts revisited the JavaScript embedded within the phishing pages themselves.
What they found was far more revealing than expected.
Part 2: When Two Kits Become One Inside the Hybrid Payload
To identify what had changed in this new wave of submissions, the code was compared against known, earlier versions of both phishing kits. Prior analyses of each framework served as the baseline for this comparison:
-
Salty2FA
-
Tycoon2FA
With those reference points established, the investigation turned to a representative sample that clearly demonstrated the shift in behavior.
Check analysis session
The attack chain starts with a phishing page hosted on Cloudflare Pages Dev, a service designed for front end development and static website hosting. Its ease of deployment has made it a frequent target for abuse by threat actors.
A closer inspection of the page reveals several recognizable traits. The markup contains embedded “motivational quotes,” and the CSS class names follow a basic word-plus-number naming pattern. These artifacts strongly mirror characteristics seen in earlier versions of the Salty2FA codebase features that may appear trivial, but are anything but benign.
Further down the script, the familiar “trampoline” logic appears the mechanism responsible for pulling in the next stage of the payload and injecting it into the DOM. This sequence matches the older Salty2FA implementation almost exactly.
The notable twist comes next. Comments within the code acknowledge that the primary payload may fail to load, instructing the script to retrieve the next stage from a secondary source instead. That fallback URL is hard-coded directly into the script, with no obfuscation applied an unusual choice that immediately stands out during analysis.
After decoding the function argument, the script reveals the URL hxxps://omvexe[.]shop/ an indicator of compromise previously linked to Salty2FA. Interestingly, the payload is never actually retrieved. When the script tries to resolve the domain, the DNS query returns SERVFAIL, not NXDOMAIN (which indicates a non-existent domain).
A SERVFAIL response signals a server-side problem, such as misconfigured name server records or delegation issues, where the resolver cannot identify the authoritative DNS server for the domain. This explains why the fallback payload fails to load, despite being hard-coded into the script.
In effect, the Salty2FA infrastructure is malfunctioning, prompting the script to fall back to its secondary plan: loading the payload from a hard-coded alternate URL.
After the initial failure, the script redirects to hxxps://4inptv[.]1otyu7944x8[.]workers[.]dev/, which serves the next stage of the attack.
The first segment of this stage includes obfuscated anti-analysis checks, implemented via Base64 decoding followed by an eval() call.
The second segment is protected with a Base64-XOR obfuscation and contains the subsequent portion of the payload, ready for execution.
In effect, the Salty2FA infrastructure is malfunctioning, prompting the script to fall back to its secondary plan: loading the payload from a hard-coded alternate URL.
After the initial failure, the script redirects to hxxps://4inptv[.]1otyu7944x8[.]workers[.]dev/, which serves the next stage of the attack.
The first segment of this stage includes obfuscated anti-analysis checks, implemented via Base64 decoding followed by an eval() call.
The second segment is protected with a Base64-XOR obfuscation and contains the subsequent portion of the payload, ready for execution.
Comments
Post a Comment