Let\u2019s examine how this hybrid emerged, why it signals a shift in 2FA phishing, and what measures defenders should take in response. <\/p>\n\n\n\n
Key Takeaways <\/h2>\n\n\n\n\n- Salty2FA activity collapsed abruptly in late October 2025<\/strong>, dropping from hundreds of weekly uploads to ANY.RUN\u2019s Interactive Sandbox<\/a> to just a few dozen. <\/li>\n<\/ul>\n\n\n\n
\n- New samples began showing overlapping indicators from both Salty2FA and Tycoon2FA<\/strong>, including shared IOCs, TTPs, and detection rule triggers. <\/li>\n<\/ul>\n\n\n\n
\n- Code-level analysis confirmed hybrid payloads<\/strong>: early stages matched Salty2FA, while later stages reproduced Tycoon2FA\u2019s execution chain almost line-for-line. <\/li>\n<\/ul>\n\n\n\n
\n- Salty2FA infrastructure showed signs of operational failure<\/strong>, forcing samples to fall back to Tycoon-based hosting and payload delivery. <\/li>\n<\/ul>\n\n\n\n
\n- The overlap aligns with earlier hypotheses suggesting a possible connection to Storm-1747<\/strong>, who are known operators of Tycoon2FA. <\/li>\n<\/ul>\n\n\n\n
\n- Attribution remains essential<\/strong>: Distinguishing between these \u201c2FA\u201d phishing kits helps analysts maintain accurate hunting hypotheses and track operator behavior. <\/li>\n<\/ul>\n\n\n\n
\n- Defenders should update detection logic<\/strong> to account for scenarios where Salty2FA and Tycoon2FA appear within the same campaign or even a single payload. <\/li>\n<\/ul>\n\n\n\n
\n- More cross-kit overlap is likely<\/strong>, meaning future phishing campaigns may blend infrastructures, payloads, and TTPs across frameworks. <\/li>\n<\/ul>\n\n\n\n
Part 1: Numbers Don\u2019t Lie – A Sudden Drop in Salty2FA Activity <\/h2>\n\n\n\n
It all started around the end of October 2025, when the number of\u00a0the ANY.RUN sandbox submissions<\/a>\u00a0showing activity linked to Salty2FA dropped sharply compared to\u00a0previous\u00a0periods.\u00a0<\/p>\n\n\n\nWeekly phishing reports (see the company\u2019s X posts<\/a>) show that, despite the usual fluctuations in overall upload volume, the average number of Salty2FA-related analysis sessions consistently stayed in the range of several hundred per week. <\/p>\n\n\n\nHowever, once November began, the decline became dramatic: By November 11, 2025<\/a>, Salty2FA had fallen to the bottom of the weekly threat rankings, with only 51 submissions<\/strong>, compared to its typical 250+ per week<\/strong>. <\/p>\n\n\n\n![\"\"](\"\/cybersecurity-blog\/wp-content\/uploads\/2025\/12\/image-1024x495.jpg\")
Fig.1: Salty2FA activity chart<\/em> <\/figcaption><\/figure><\/div>\n\n\nAlong with indicators of compromise (IOCs) and hunting rules, the ANY.RUN sandbox\u2019s network block<\/strong> previously triggered a near-constant alert tied to Salty-specific HTTP activity. <\/p>\n\n\n\n![\"\"](\"\/cybersecurity-blog\/wp-content\/uploads\/2025\/12\/image2-1-1024x483.png\")
Fig.2: Last sandbox analyses showing detection of Salty2FA TTPs<\/em> <\/figcaption><\/figure><\/div>\n\n\nThis refers to the Suricata rule sid:85002719<\/strong>. If we filter Public submissions <\/em>for analysis sessions where this rule fired, the most recent match dates back to 2025-11-01<\/strong>: <\/p>\n\n\n\nCheck recent analysis session<\/a> <\/p>\n\n\n\nThe first assumption was obvious: the detection logic became outdated, the framework received an update, and analysts simply hadn\u2019t refreshed the signatures in time. But what about infrastructure indicators or domains<\/strong>? <\/p>\n\n\n\nWhile IOCs sit lower on the Pyramid of Pain than Tools\/TTP coverage, they are easy to track at scale and often remain in use long enough to provide meaningful visibility. They often remain active for some time, leaving repeated traces in the data. These recurring indicators make it easier for analysts to track the threat, update its context, and perform wider hunting to uncover new related domains, behaviors, and activity patterns. <\/p>\n\n\n\n
The plan was simple: search for recent analysis sessions tagged with the threat name in ANY.RUN\u2019s Threat Intelligence Lookup<\/a>, examine changes in the kit\u2019s behavior and client-side code, and then update the detection methods: <\/p>\n\n\n\nthreatName:”salty2fa”<\/a> <\/p>\n\n\n\n![\"\"](\"\/cybersecurity-blog\/wp-content\/uploads\/2025\/12\/image15-1024x580.png\")
Fig.3: TI Lookup provides a complete overview of the latest Salty2FA attacks <\/em> <\/figcaption><\/figure><\/div>\n\n\nBut then things became even more unusual. In almost every analysis executed after November 1<\/strong>, the samples were either completely non-functional (examples 1<\/a>, 2<\/a>, 3<\/a>) or behaved in ways that didn\u2019t align with Salty2FA at all. <\/p>\n\n\n\n\n
- \n
- New samples began showing overlapping indicators from both Salty2FA and Tycoon2FA<\/strong>, including shared IOCs, TTPs, and detection rule triggers. <\/li>\n<\/ul>\n\n\n\n
- \n
- Code-level analysis confirmed hybrid payloads<\/strong>: early stages matched Salty2FA, while later stages reproduced Tycoon2FA\u2019s execution chain almost line-for-line. <\/li>\n<\/ul>\n\n\n\n
- \n
- Salty2FA infrastructure showed signs of operational failure<\/strong>, forcing samples to fall back to Tycoon-based hosting and payload delivery. <\/li>\n<\/ul>\n\n\n\n
- \n
- The overlap aligns with earlier hypotheses suggesting a possible connection to Storm-1747<\/strong>, who are known operators of Tycoon2FA. <\/li>\n<\/ul>\n\n\n\n
- \n
- Attribution remains essential<\/strong>: Distinguishing between these \u201c2FA\u201d phishing kits helps analysts maintain accurate hunting hypotheses and track operator behavior. <\/li>\n<\/ul>\n\n\n\n
- \n
- Defenders should update detection logic<\/strong> to account for scenarios where Salty2FA and Tycoon2FA appear within the same campaign or even a single payload. <\/li>\n<\/ul>\n\n\n\n
- \n
- More cross-kit overlap is likely<\/strong>, meaning future phishing campaigns may blend infrastructures, payloads, and TTPs across frameworks. <\/li>\n<\/ul>\n\n\n\n
Part 1: Numbers Don\u2019t Lie – A Sudden Drop in Salty2FA Activity <\/h2>\n\n\n\n
It all started around the end of October 2025, when the number of\u00a0the ANY.RUN sandbox submissions<\/a>\u00a0showing activity linked to Salty2FA dropped sharply compared to\u00a0previous\u00a0periods.\u00a0<\/p>\n\n\n\n
Weekly phishing reports (see the company\u2019s X posts<\/a>) show that, despite the usual fluctuations in overall upload volume, the average number of Salty2FA-related analysis sessions consistently stayed in the range of several hundred per week. <\/p>\n\n\n\n
However, once November began, the decline became dramatic: By November 11, 2025<\/a>, Salty2FA had fallen to the bottom of the weekly threat rankings, with only 51 submissions<\/strong>, compared to its typical 250+ per week<\/strong>. <\/p>\n\n\n
\nFig.1: Salty2FA activity chart<\/em> <\/figcaption><\/figure><\/div>\n\n\n Along with indicators of compromise (IOCs) and hunting rules, the ANY.RUN sandbox\u2019s network block<\/strong> previously triggered a near-constant alert tied to Salty-specific HTTP activity. <\/p>\n\n\n
\nFig.2: Last sandbox analyses showing detection of Salty2FA TTPs<\/em> <\/figcaption><\/figure><\/div>\n\n\n This refers to the Suricata rule sid:85002719<\/strong>. If we filter Public submissions <\/em>for analysis sessions where this rule fired, the most recent match dates back to 2025-11-01<\/strong>: <\/p>\n\n\n\n
Check recent analysis session<\/a> <\/p>\n\n\n\n
The first assumption was obvious: the detection logic became outdated, the framework received an update, and analysts simply hadn\u2019t refreshed the signatures in time. But what about infrastructure indicators or domains<\/strong>? <\/p>\n\n\n\n
While IOCs sit lower on the Pyramid of Pain than Tools\/TTP coverage, they are easy to track at scale and often remain in use long enough to provide meaningful visibility. They often remain active for some time, leaving repeated traces in the data. These recurring indicators make it easier for analysts to track the threat, update its context, and perform wider hunting to uncover new related domains, behaviors, and activity patterns. <\/p>\n\n\n\n
The plan was simple: search for recent analysis sessions tagged with the threat name in ANY.RUN\u2019s Threat Intelligence Lookup<\/a>, examine changes in the kit\u2019s behavior and client-side code, and then update the detection methods: <\/p>\n\n\n\n
threatName:”salty2fa”<\/a> <\/p>\n\n\n
\nFig.3: TI Lookup provides a complete overview of the latest Salty2FA attacks <\/em> <\/figcaption><\/figure><\/div>\n\n\n But then things became even more unusual. In almost every analysis executed after November 1<\/strong>, the samples were either completely non-functional (examples 1<\/a>, 2<\/a>, 3<\/a>) or behaved in ways that didn\u2019t align with Salty2FA at all. <\/p>\n\n\n\n\n
- More cross-kit overlap is likely<\/strong>, meaning future phishing campaigns may blend infrastructures, payloads, and TTPs across frameworks. <\/li>\n<\/ul>\n\n\n\n
- Defenders should update detection logic<\/strong> to account for scenarios where Salty2FA and Tycoon2FA appear within the same campaign or even a single payload. <\/li>\n<\/ul>\n\n\n\n
- Attribution remains essential<\/strong>: Distinguishing between these \u201c2FA\u201d phishing kits helps analysts maintain accurate hunting hypotheses and track operator behavior. <\/li>\n<\/ul>\n\n\n\n
- The overlap aligns with earlier hypotheses suggesting a possible connection to Storm-1747<\/strong>, who are known operators of Tycoon2FA. <\/li>\n<\/ul>\n\n\n\n
- Salty2FA infrastructure showed signs of operational failure<\/strong>, forcing samples to fall back to Tycoon-based hosting and payload delivery. <\/li>\n<\/ul>\n\n\n\n
- Code-level analysis confirmed hybrid payloads<\/strong>: early stages matched Salty2FA, while later stages reproduced Tycoon2FA\u2019s execution chain almost line-for-line. <\/li>\n<\/ul>\n\n\n\n