How Tycoon 2FA Is Rewriting the Rules of Identity Theft: Not Just a Phishing Kit – A Business Model

Introduction

In 2026, the most dangerous thing on your network isn’t ransomware. It’s a login page.

Tycoon 2FA phishing is not an “attack campaign.” It is a Phishing-as-a-Service (PhaaS) business model – a turnkey operation that sells MFA-bypass capabilities to low-skill actors, scales globally, and adapts faster than most security teams can respond.

This is the era where enabling multi-factor authentication is no longer a silver bullet. It is table stakes. The real threat lives in the infrastructure that sits between you and your login page, silently relaying your credentials, your MFA approvals, and your sessions to an adversary who never needs to write a single line of code.

If your security strategy still assumes “enable MFA and you’re safe,” Tycoon is quietly proving you wrong.

The Age of Phishing-as-a-Service and the Death of “Just Enable MFA”

In 2026, the cybersecurity landscape is defined not by individual malware samples, but by platforms that weaponize identity. Tycoon 2FA is the poster child of this shift.

Unlike traditional phishing, Tycoon is a managed service sold on Telegram and dark-web marketplaces for as low as $120 for 10 days of access. It is used by financially motivated threat actors, e-crime groups, and even script-kiddies who rent access instead of building their own infrastructure.

The result? A plug-and-play MFA-bypass platform that turns identity into a commodity.

The MFA Myth Is Dead

MFA was never designed to stop session hijacking. Tycoon doesn’t crack your second factor. It relays it.

The result:

• Your users approve push notifications, SMS codes, or authenticator prompts, thinking they’re logging in normally.
• Tycoon captures the session cookie and hands it to the attacker.
• The attacker now has a live, authenticated session—no password cracking, no malware, no brute-forcing.

From the victim’s perspective, nothing feels wrong. From the attacker’s perspective, MFA is a feature, not a barrier.

What Is Tycoon 2FA Phishing — And Why It Matters

Tycoon 2FA is a commercial phishing kit sold on underground channels as a PhaaS platform. First observed in August 2023, it has evolved into one of the most widely deployed Adversary-in-the-Middle (AiTM) tools targeting Microsoft 365, Gmail, and other identity-driven services.

Unlike traditional phishing, Tycoon is not a one-off script. It is a managed service:

• Reverse‑proxy infrastructure that hosts fake login pages for Microsoft 365, Gmail, and other identity‑driven services.
• Session‑cookie capture that bypasses MFA by relaying approvals in real‑time.
• Anti‑analysis features that block sandboxes, bot traffic, and manual inspection.
• Used by financially motivated threat actors, e-crime groups, and even script-kiddies who rent access instead of building their own infrastructure.
• Designed for scale: one backend can support multiple phishing pages, multiple domains, and multiple campaigns simultaneously.

In short, Tycoon is the Shopify of phishing. You pay, you get a template, and you start harvesting sessions.

How Adversary-in-the-Middle (AiTM) Attacks Work

At its core, Tycoon uses an Adversary-in-the-Middle (AiTM) architecture. Think of it as a relay attack on your login flow.

Here’s a simple analogy:
Imagine you’re calling a bank to verify a transaction. The call center transfers you to “security,” but the transfer is actually to a third party who listens to everything, repeats your answers, and then hangs up. You never realize someone else was in the conversation.

Technically, this is what happens:

1. The victim visits a Tycoon-hosted fake login page (e.g., Microsoft 365 or Gmail).
2. Tycoon acts as a reverse proxy, forwarding credentials to the real service.
3. The real service sends an MFA prompt (push notification, SMS, etc.).
4. Tycoon relays that prompt to the victim, who approves it thinking they are logging in normally.
5. Tycoon captures the resulting session cookie and hands it to the attacker, who now has a live, authenticated session.

From the victim’s perspective, everything looks normal. From the attacker’s perspective, MFA has been bypassed, not broken.

Global Impact to Date

Tycoon has become one of the most active AiTM phishing platforms in the world. By 2025, it had already been linked to more than tens of thousands of credential-harvesting incidents, with victims spanning enterprises, government agencies, and cloud-first businesses.

Key patterns:

• Industries hit hardest: Financial services, technology, healthcare, and professional services – anywhere identity is the primary attack surface.
• Geographic spread: Strong presence in the US, UK, Canada, and India, reflecting both the concentration of cloud-based workforces and the availability of PhaaS infrastructure.​
• Why enterprises keep falling:
  • Overreliance on MFA as a standalone control.
  • Inadequate detection of AiTM-style session hijacking.
  • Persistent use of legacy email security that struggles with HTML-based lures and obfuscated JavaScript.

Tycoon is not a niche threat. It is a baseline capability in the modern phishing toolkit.

Overview of Discovery – TLDR

What if turning on MFA no longer keeps your accounts safe?

Tycoon 2FA is a phishing-as-a-service (PhaaS) platform that rents out ready-made adversary-in-the-middle (AiTM) login pages. Instead of breaking MFA, it relays MFA prompts and steals live session cookies, giving attackers a fully authenticated session without ever defeating the second factor.

In plain terms, a user believes they are logging in normally and approves an MFA request. Behind the scenes, Tycoon sits between the victim and the real service, forwards the authentication flow in real time, captures the active session, and hands it to the attacker. The platform is scalable, sold on underground markets, and engineered to evade detection using CAPTCHAs, anti-debugging JavaScript, and rotating multi-domain infrastructure.

Why this matters is simple: organizations across finance, technology, healthcare, and government still treat MFA as a silver bullet. Tycoon turns digital identity into a commodity – allowing even low-skill actors to buy access and compromise accounts at scale.

At a technical level, Tycoon functions as an AiTM proxy. It intercepts the entire authentication workflow, forwarding credentials to the legitimate service, relaying MFA challenges back to the victim, and capturing authenticated session cookies or tokens once MFA is approved. The attacker never needs to defeat MFA – they simply inherit a trusted session, which can be replayed from their own infrastructure until it expires or is revoked.

To remain effective, Tycoon layers multiple evasion techniques:

• Dynamic JavaScript obfuscation to block inspection and analysis
• CAPTCHAs and browser fingerprinting to filter bots and sandboxes
• Rapid domain rotation to evade takedowns and reputation-based defenses

In short, Tycoon doesn’t break authentication – it abuses trust in authenticated sessions, exposing a critical blind spot in MFA-centric security strategies.

Quick, practical takeaways:

• Treat session integrity as a first-class signal by monitoring anomalous session behavior and revoking suspicious sessions.
• Harden conditional access with device posture checks, step-up authentication, and geo-based risk controls.
• Train users to recognize workflow anomalies, such as unexpected CAPTCHAs, unfamiliar URLs, or MFA prompts that arrive out of context.

Technical Breakdown: Inside the Tycoon 2FA Kill Chain

This section dissects the Tycoon 2FA phishing kit’s anatomy through hands‑on analysis of real‑world samples targeting organizations such as Lee Associates. While the kit can target any organization, the sample analyzed here was a spear‑phishing attack against an employee of Lee Associates, which is why the organization is referenced explicitly. Each figure is more than a screenshot; it serves as evidence of deliberate tactical choices designed to evade detection, manipulate user psychology, and scale credential theft across enterprises.

At first glance, the email is indistinguishable from legitimate corporate communication. The subject line reads: “New V-Mail from David” — suggesting an internal voice message. And also displays a professionally formatted notification panel titled: “You Have (1) New Voice Message” with a prominent blue button: “Click attached to Play Voice Message.” The panel mimics the exact layout, color scheme, and typography of real enterprise voicemail systems- Microsoft Teams, Cisco Webex, or internal PBX systems, as shown in Figure 1.

Beneath this polished exterior lies the HTML attachment – the true attack vector. It is not a voicemail player. It is a redirect agent that will chain the victim through multiple stages of compromise, each one building on the deception of the previous.

At first glance, the sender email address and the recipient email address appear to be the same, making it seem as though the email was sent to the self account, as shown in Figure 1. However, this is not the case; this behaviour is a classic example of email spoofing.

To verify this, an email header inspection was performed using a text editor, which revealed a sender spoofing attempt through analysis of the message’s SMTP relay path and authentication results, as shown in Figure 2. The headers clearly indicate an SPF failure, the absence of DKIM, and a DMARC failure, confirming that the sender was not authorized to send email on behalf of the claimed domain.

Additionally, the originating IP address (45.56.165.245) does not belong to the legitimate sender’s mail infrastructure and is flagged during validation. Although the message passed through Microsoft mail servers, the authentication failures confirm that the email was spoofed rather than legitimately sent.

Despite these glaring failures, the email passed through Microsoft mail servers and reached the victim’s inbox.

Traditional email security focuses on executables (.exe, .dll) and macros (Word, Excel). HTML attachments slip through because they appear “safe”- after all, browsers render HTML every second without incident. But Tycoon exploits this blind spot.

When opened, the HTML file doesn’t display a voicemail player. It executes obfuscated JavaScript that has one job: silently redirect the victim to attacker infrastructure while tracking their identity.

The fig 3 above shows the contents of the HTML file attached to the phishing email, opened in a code editor, appearing as an impenetrable wall of minified, obfuscated JavaScript. Common tactic used to conceal malicious intent and evade both static analysis and email security scanning. This obfuscation is designed to prevent quick identification of the file’s true behaviour when viewed casually or scanned automatically.

After de-obfuscating the script, the underlying functionality becomes clear. The HTML file does not play any voicemail audio or load legitimate content. Instead, it performs a silent redirection when opened.

The decoded logic reveals that the page redirects the victim’s browser to the following external URL:

https://mapbox.stashiowio.us/EVyi@VC11WbK13yyFdX/$000000000000bGVlLWFzc29jaWF0ZXMuY29t

Notably, the redirected URL contains an encoded value that maps back to the recipient’s email address, indicating that the phishing infrastructure is capable of tracking or uniquely identifying victims. This technique is commonly used to personalize phishing pages often called as Spear phishing, validate targets, or pre-fill login fields to increase credibility.

In summary, the attached HTML file serves as the primary attack vector in this campaign. Its sole purpose is to execute obfuscated JavaScript that redirects the user to an attacker-controlled phishing endpoint, rather than delivering any legitimate voicemail content.

Just a smooth, invisible chain to the next compromise stage.

At this point, the attacker faces a critical problem: automated sandboxes and security crawlers are also clicking links. If the phishing page loads indiscriminately, it gets flagged, analyzed, and blocked within hours. The attacker needs to filter traffic – allowing only real humans while blocking bots, researchers, and defenses – the solution: fake CAPTCHA.

Figure 4 displays a Cloudflare-style verification prompt: “I am not a robot” with a checkbox. Below it: “Verification successful.” The design is pixel-perfect to Cloudflare’s real interface – familiar wording, recognizable layout, standard fonts.

Here’s the surgical genius: users trust Cloudflare. They see this prompt on millions of legitimate sites daily. Their brain automatically categorizes this as “normal security.” They click the checkbox. Verification passes. They proceed, completely unaware they’re still in the attacker’s domain.

The Traffic Filtering Effect – This gate blocks:

• Automated security crawlers (can’t solve CAPTCHAs without plugins).
• Sandbox environments (detection triggers on CAPTCHA-solving attempts).
• Researchers analyzing URLs directly (bots can’t proceed).
• Email security scanners (non-human traffic blocked).

Only real humans with real browsers advance to the next stage. This is why traditional URL-scanning misses Tycoon: the phishing page itself is invisible to automated tools.

The Psychological Reinforcement – The CAPTCHA doesn’t just filter; it builds false confidence. Users think: “I’m being verified by legitimate security. This site is safe.” In reality, they’re being sorted into victim vs. non-victim buckets.

After CAPTCHA validation, the victim is redirected to what appears to be their organization’s Microsoft 365 login page. Fig 5 shows a Lee & Associates-branded portal: company logo, organization name, familiar blue Microsoft color scheme, and a login prompt: “Enter password to access office mail.”

To the victim, this is home. This is the page they see every morning. The layout matches. The branding matches. The language matches.

The Deception: URL Reality vs. Visual Fiction

Examine the browser address bar. The domain is not microsoft.com or any legitimate subdomain. It’s a foreign URL, hosted on attacker infrastructure. Yet the user doesn’t check the URL. Their eyes lock onto the familiar logo and workflow. Their fingers type their password.

To investigate the phishing page further, browser developer tools were used to inspect the site’s behavior. However, the page actively attempts to prevent analysis through injected JavaScript controls.

As shown in the figure 6, the phishing site loads multiple JavaScript files that execute anti-debugging and anti-inspection logic as soon as the page is accessed. These scripts are designed to interfere with normal browser investigation techniques by:

• Disabling right-click context menus
• Blocking common keyboard shortcuts used to open developer tools or inspect elements
• Detecting when developer tools are opened
• Triggering debugger statements to pause execution and disrupt analysis

Because this JavaScript is executed before the page fully renders, it effectively prevents users from opening developer tools after landing on the site. In this case, the developer console shows execution being repeatedly paused due to injected debugger statements, making live inspection difficult.

The presence of such anti-analysis mechanisms further reinforces that this page is not a legitimate Microsoft login portal, but a carefully engineered phishing page designed to protect its own malicious infrastructure.

To go with the further investigation, we used the tool called Burp Suite (an HTTP interceptor). Burp Suite analysis revealed the request which got response which was the JavaScript code appears as an impenetrable blob of minified code as seen in figure 7.

Inspecting the JavaScript code, I noticed that it was heavily obfuscated. After de-obfuscating it, I discovered that the script implements multi-layered anti-analysis techniques commonly seen in phishing frameworks.

It first performs environment detection to identify automation tools, headless browsers, or interception proxies like Burp Suite and immediately redirects away to Blank if found. The code then blocks developer tools, keyboard shortcuts, and right-click actions, preventing source inspection and manual analysis. Finally, it uses debugger timing detection to identify active DevTools sessions and forcefully redirects the user away. Overall, the purpose is to evade forensic analysis, sandboxing, and reverse engineering, protecting the phishing infrastructure from investigation as shown in figure 8.

And further inspecting the de-obfuscated code found the JavaScript which injects the fake cPanel error page. As the initial script was encoded in the base64 as shown in figure 9 and after decoding it, it was representing a fake cPanel error page used as a decoy payload by the phishing infrastructure.

When the script detects an unexpected domain, incorrect path, or analysis conditions, it injects a Base64-encoded HTML page that mimics a legitimate hosting error as seen in figure 10. The decoy is designed to mislead investigators into thinking the site is misconfigured or inactive, reducing suspicion. In reality, this page is intentionally served only to non-victim traffic, while real targets receive the phishing content.

Upon further analysis, a request-response interaction with api.ipbase.com was observed, which is a legitimate third-party IP intelligence API.

Figure 11 shows the phishing page abusing the api.ipbase.com service to collect a visitor’s IP address and geolocation data. The API response provides details such as country, region, city, latitude, longitude, and timezone, enabling precise victim profiling. Attackers use this information for geo-fencing and traffic filtering, ensuring only intended targets are served the phishing payload.

This abuse of a legitimate IP intelligence API helps evade sandboxes and security researchers while increasing the success rate of the campaign.

Upon further analysis found one more heavily obfuscated JavaScript as seen in figure 12. So I analysed that one and it was also injecting the Decoy pages too and these were Microsoft Fake pages as shown in figure 13. But these pages weren’t loaded as this sample was targeting the employee of Lee & Associates.

Continued the analysis and got the answer to my question. Fig 14 captures a network request showing the phishing page dynamically loading legitimate Microsoft Azure AD branding directly from Microsoft’s CDN. This means:

• The logo is real (pulled from Microsoft servers).
• The styling is real (pulled from Azure).
• The entire visual experience is indistinguishable from the genuine portal.

Why does this matter? Because:

• Visual-based detection fails (users can’t spot fakes if assets are authentically sourced).
• Reverse-engineering is harder (researchers chasing legitimate CDN requests down rabbit holes).
• The attacker doesn’t host the branding (reducing infrastructure fingerprints).

The attacker is stealing legitimacy in real-time, using Microsoft’s own CDN as an unwitting accomplice.

Upon further inspection found the credential exfiltration mechanism. The figure 15 captures a POST request sent from the phishing page to a backend endpoint hosted on mapbox.stashiowio.us, masquerading as a legitimate service. The request body contains a highly obfuscated and encoded payload, indicative of stolen user input, most likely harvested login credentials.

Use of XHR requests, Laravel session cookies, and XSRF tokens suggests a deliberately structured backend designed to appear legitimate. The response confirms successful data receipt (HTTP 200), indicating that the exfiltration channel is active. This mechanism demonstrates how the campaign covertly collects and forwards victim credentials while blending into normal web traffic.

This figure 16 illustrates a POST request sent from the phishing page (mapbox.stashiowio.us) to an external endpoint (date.woosea.biz.id), indicating active data exfiltration. The request contains an encoded and obfuscated payload within the application/x-www-form-urlencoded body, consistent with harvested credentials or session data.

Use of randomized URI paths and Cloudflare-fronted infrastructure helps obscure the attacker’s backend and evade detection. The server responds with HTTP 200 OK, confirming successful receipt of the stolen data. This interaction highlights the campaign’s multi-domain architecture designed to stealthily collect and relay victim credentials.

Why multiple domains?

• Redundancy: If one backend is blocked/seized, the other catches the data.
• Attribution confusion: Researchers see traffic going to multiple unrelated domains, making correlation difficult.
• C2 compartmentalization: Each domain serves different functions:
  • mapbox.stashiowio.us: Credential ingestion.
  • date.woosea.biz.id: Secondary exfiltration/relay.
  • Unknown domains: Session management, MFA token handling.

This multi-domain architecture is the hallmark of a mature PhaaS operation. The infrastructure is resilient, redundant, and deliberately fragmented.

To prove that Tycoon is a coordinated PhaaS operation - not a one-off campaign - examine samples targeting different organizations

Similar to the analysis conducted on the Lee & Associates spear-phishing sample, the following figures demonstrate how the Tycoon 2FA phishing campaign can target employees across different organisations. Figure 17 illustrates a spear-phishing attack targeting a Bridgestone employee, where human verification is implemented through image-based CAPTCHA selection.

Figure 18 represents a similar attack against an HKA employee, but with a text-based CAPTCHA requiring manual value entry.

This variation highlights Tycoon’s adaptive use of multiple human-verification mechanisms to bypass automated analysis and security controls. Upon successful CAPTCHA validation, victims are redirected to pixel-perfect, organisation-specific decoy login pages. These cloned portals ultimately trick users into submitting valid credentials and 2FA codes, completing the credential harvesting workflow.

Infrastructure Correlation

Figure 19 represents a Maltego-driven infrastructure investigation of a Tycoon 2FA phishing URL and its associated backend ecosystem.

The initial phishing link resolves to multiple domains and IP addresses, revealing a distributed hosting model commonly used to evade takedowns. Parallel analysis of the domain (date.woosea.biz.id), identified during credential exfiltration via an obfuscated cross-site POST request, exposes overlapping infrastructure. Pivoting across DNS records, IP addresses, and netblocks highlights a shared backend IP range reused by both phishing delivery and data exfiltration components.

This shared netblock acts as a strong indicator of cross-campaign correlation rather than incidental overlap or shared hosting providers. Additional netblocks are observed but assessed as auxiliary or campaign-specific infrastructure. The reuse of backend IP space across distinct domains demonstrates operational continuity and centralised control.

Overall, the image confirms that Tycoon’s phishing campaigns are not isolated deployments but part of a coordinated, scalable phishing-as-a-service operation.

Evasion Evolution: Tycoon 2023 → 2025

Tycoon 2FA phishing kit has evolved rapidly since its emergence, with mutations focused on evasion, obfuscation, and anti-analysis to counter defender tools. Tycoon did not just improve – it learned. This timeline, compiled from threat intelligence reports, tracks key updates through early 2026.

Tycoon 2FA Evolution Timeline table

Date/Period	Key Mutations & Features Added
Aug 2023	Initial emergence as PhaaS platform; basic AiTM reverse proxy for credential/session cookie theft targeting Microsoft 365/Gmail; admin panel similar to Dadsec OTT.
Mar 2024	Heavy JavaScript/HTML obfuscation; dynamic code generation to evade signatures; enhanced detection evasion.
Nov 2024	Advanced anti-analysis: blocks dev tools, right-click, clipboard overwrite; detects inspection keystrokes (F12, Ctrl+Shift+I); redirects on suspicion.
Dec 2024	Dynamic multimedia: victim domain-matched logos/backgrounds for realism.​
Early 2025 (Jan–Mar)	Custom HTML5 canvas CAPTCHA (replaces Cloudflare Turnstile); invisible Unicode obfuscation; anti-debugging scripts; extended redirect chains.​
Apr 2025	Rotating CAPTCHAs (Google reCAPTCHA, IconCaptcha, custom); whitespace-based encoding; longer redirect chains.
May 6, 2025	Full browser fingerprinting (screen, browser props, timezone, etc.) for sandbox evasion; AES encryption on final payloads (beyond just exfil data).
Late 2025 (post-May)	Ongoing refinements: improved WebSocket exfil, personalized lures (QR codes, payroll fakes); ties to other PhaaS like Dadsec noted; no major public breaks reported into 2026.

Primary Tactics & Techniques

Tactic (ID)	Technique (ID)	Description in Tycoon Context
Initial Access (TA0001)	Phishing: Spearphishing Attachment (T1566.001)	Malicious attachments or links in emails/SMS lure victims to phishing pages mimicking Microsoft 365/Gmail.
	Phishing: Spearphishing Link (T1566.002)
Execution (TA0002)	Command and Scripting Interpreter: JavaScript (T1059.007)	Heavy obfuscated JS on phishing page handles proxying, data exfil via WebSockets, and anti-debug logic.​
Credential Access (TA0006)	Steal Web Session Cookie (T1539)	Captures authenticated session cookies post-MFA via AiTM reverse proxy, enabling account takeover.
	Input Capture: Web Forms (T1110)	Real-time capture and relay of credentials, MFA challenges, and OTPs to legitimate IdP (AiTM)..​
Defense Evasion (TA0005)	Obfuscated Files or Information (T1027)	JS/HTML obfuscation, LZString compression, Unicode tricks, dynamic code gen to evade static analysis.​
	Masquerading (T1036)	Look-alike domains, cloned login workflows, valid TLS certificates, and legitimate branding assets loaded from Microsoft CDNs create convincing replicas of real authentication portals.
	Virtualization / Sandbox Evasion (T1497)	Detects headless browsers, automation, debuggers, and sandboxes; redirects suspicious users.
Discovery (TA0007)	Browser Information Discovery (T1528)	Browser and environment fingerprinting (UA, screen, timezone, language) for filtering and geo-fencing.
Command and Control (TA0011)	Application Layer Protocol: Web (HTTPS) (T1071.001)	All attacker–victim communication occurs over HTTPS, blending malicious traffic with normal web activity and reducing network-level detection.
	Proxy (T1090)	Phishing page loads via redirects; WebSockets for real-time credential relay to C2.​
Exfiltration (TA0010)	Exfiltration Over Web Service (T1560.001)	Stolen creds/cookies exfiled via WebSockets to attacker panel/Telegram.

Recommendations: Surviving the AiTM Era

Session Integrity > Credential Security

The future of identity security lies in session integrity, not just credential protection. This means:

• Monitoring for unusual session behavior (e.g., logins from unexpected locations or devices).
• Detecting session hijacking at the network or endpoint level.
• Using conditional access policies that restrict access based on risk signals.

Identity Telemetry

Organizations need rich identity telemetry that goes beyond logs. This includes:

• Real-time monitoring of login attempts.
• Correlation of MFA approvals with session activity.
• Integration with threat intelligence feeds that track PhaaS platforms like Tycoon.

Conditional Access Hardening

Conditional access policies should be risk-based, not static. For example:

• Block logins from high-risk regions or IP ranges.
• Require step-up authentication for sensitive actions.
• Automatically revoke sessions when suspicious activity is detected.

User Workflow Disruption Awareness

Users need to be trained to recognize workflow disruptions – moments when the login flow feels “off.” This includes:

• The Golden Rule always verify the links you are browsing to or being redirected to before entering any credentials.
• Unexpected CAPTCHAs or verification steps.
• MFA prompts that don’t match the context of the login.

Conclusion: Tycoon Is the Blueprint

Tycoon is not an outlier. It is a preview of the future of phishing.

In 2026, the threat landscape is defined not by individual malware samples, but by platforms that sell access to MFA-bypass capabilities, scale globally, and evolve faster than defenders can respond.

The question is no longer “How do we stop phishing?” It is “How do we defend against platforms that weaponize identity?”

The answer lies in session-level monitoring, behavioral detection, and a defensive philosophy that assumes MFA will be bypassed.

Because in the AiTM era, trust is the new attack surface.

References

• https://radar.offseq.com/threat/salty2fa-tycoon2fa-hybrid-phishing-threat-59c5c85a
• https://threatlabsnews.xcitium.com/blog/tycoon-2fa-phishing-kit-the-sophisticated-threat-bypassing-modern-security/
• https://www.cybereason.com/blog/tycoon-phishing-kit-analysis
• https://www.proofpoint.com/us/blog/email-and-cloud-threats/tycoon-2fa-phishing-kit-mfa-bypass
• https://blog.barracuda.com/2025/01/22/threat-spotlight-tycoon-2fa-phishing-kit
• https://socradar.io/blog/tycoon-2fa-an-evolving-phishing-kit-phaas-threats/
• https://www.darktrace.com/blog/mfa-under-attack-aitm-phishing-kits-abusing-legitimate-services