Law Enforcement Dismantles Tycoon 2FA: Hunting the AiTM PhaaS Threat

In a significant win for global cybersecurity, a coalition led by Europol has successfully dismantled "Tycoon 2FA," one of the most prolific Phishing-as-a-Service (PhaaS) platforms in operation. Since its emergence in August 2023, this toolkit facilitated over 64,000 attacks, democratizing advanced credential theft for cybercriminals.

While the takedown is a victory, the dismantling of Tycoon 2FA does not eliminate the threat of Adversary-in-the-Middle (AiTM) attacks. For Managed Security Service Providers (MSps) and internal SOC teams, the focus must shift from awareness to active defense. Here is what you need to know about this threat and how to hunt for it in your environment.

The Anatomy of a PhaaS Operation

Tycoon 2FA operated on a subscription model, effectively lowering the barrier to entry for threat actors. For a monthly fee, even low-skilled attackers gained access to a sophisticated infrastructure capable of bypassing Multi-Factor Authentication (MFA).

This kit was particularly dangerous because it utilized an AiTM architecture. Unlike traditional phishing, which steals a password and leaves the attacker locked out by MFA, AiTM acts as a reverse proxy. The attacker sits between the victim and the legitimate service—such as Microsoft 365 or Okta—relaying credentials in real-time.

When the victim enters their username, password, and the MFA code (or approves a push notification), the attacker intercepts the session cookie. This cookie allows them to bypass the MFA step entirely and access the account as if they were the legitimate user.

Technical Deep Dive: AiTM TTPs

Understanding the Tactics, Techniques, and Procedures (TTPs) of Tycoon 2FA is crucial for detection. The platform was managed primarily via Telegram, allowing operators to configure their phishing campaigns and "harvest" stolen credentials anonymously.

Key Attack Vectors

1. Reverse Proxy Infrastructure: The phishing sites were not static clones; they were dynamic proxies forwarding requests to the legitimate login endpoint while stripping security headers.
2. Session Cookie Theft: The primary objective was not the password, but the P-Auth or SessionID cookies.
3. Evasion: Tycoon 2FA kits often used URL encoding and obfuscation to evade basic email security gateways (ESGs).

Detection and Threat Hunting

Detecting AiTM attacks requires looking beyond simple "failed login" events. Since the attacker relays the MFA challenge to the victim, the login appears successful and legitimate to the Identity Provider (IdP).

1. KQL Queries for Microsoft Sentinel/Defender

The following queries help identify potential AiTM activity by looking for anomalies in user agent strings or impossible travel scenarios that often occur when a cookie is used from a different location than the initial authentication.

Hunt for Suspicious User-Agent Consistency (M365)

SigninLogs
| where ResultType == 0
| extend DeviceDetail = parse_(DeviceDetail)
| extend UserAgent = tostring(DeviceDetail.userAgent)
| extend OS = tostring(DeviceDetail.operatingSystem)
| extend Browser = tostring(DeviceDetail.browser)
// Flag potential AiTM proxies that often present generic or mismatched User-Agents
| where UserAgent contains "HeadlessChrome" or Browser == "Unknown" 
or OS == "Unknown"
| summarize Count = count() by UserPrincipalName, UserAgent, IPAddress, bin(TimeGenerated, 1h)
| where Count > 3
| project-reorder TimeGenerated, UserPrincipalName, IPAddress, UserAgent, Count


**Hunt for "Impossible Travel" (Session Token Theft)**

SigninLogs
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, LocationDetails = parse_(LocationDetails), IPAddress
| evaluate geo_distance_between(LocationDetails.coordinates.latitude, LocationDetails.coordinates.longitude, 
LocationDetails.coordinates.latitude, LocationDetails.coordinates.longitude) 
// Note: In a real scenario, you compare the Location of current login vs previous login. 
// This simplified query looks for logins from distinct countries within a short window.
| summarize Countries = dcount(LocationDetails.countryOrRegion), IPList = make_set(IPAddress) by UserPrincipalName, bin(TimeGenerated, 30m)
| where Countries > 1
| project-reorder TimeGenerated, UserPrincipalName, Countries, IPList

2. Python Script for URL Analysis

SOC analysts often receive lists of suspicious URLs. This Python script uses tldextract to identify potential AiTM landing pages by looking for suspicious subdomain structures often used in reverse proxy attacks (e.g., login-verify.microsoft.com.attack-domain.com).

import tldextract
import re

def analyze_phas_urls(url_list):
    """
    Analyzes a list of URLs for potential AiTM/PhaaS characteristics.
    Looks for brand names in subdomains or suspicious TLD patterns.
    """
    target_brands = ['microsoft', 'office365', 'adp', 'okta', 'google', 'paypal']
    potential_threats = []

    for url in url_list:
        try:
            extracted = tldextract.extract(url)
            subdomain = extracted.subdomain.lower()
            
            # Check if a known brand name appears in the subdomain but not the root domain
            brand_in_sub = any(brand in subdomain for brand in target_brands)
            brand_in_domain = any(brand in extracted.domain.lower() for brand in target_brands)
            
            # Heuristic: Brand is in subdomain, but the registered domain is NOT the brand
            # e.g., login-microsoft[.com].verify-account[.net]
            if brand_in_sub and not brand_in_domain:
                potential_threats.append({
                    "url": url,
                    "risk_reason": "Brand impersonation in subdomain",
                    "subdomain": subdomain,
                    "registered_domain": extracted.registered_domain
                })
                
        except Exception as e:
            print(f"Error parsing URL {url}: {e}")
            continue

    return potential_threats

# Example Usage
sus_urls = [
    "https://www.microsoft.com", 
    "https://login-verify.office365.secure-login-update.com",
    "https://adp-employees.auth-check.net"
]

threats = analyze_phas_urls(sus_urls)
for threat in threats:
    print(f"[ALERT] Found potential AiTM site: {threat['url']}")

Mitigation Strategies

Blocking the Tycoon 2FA infrastructure is helpful, but defenders must assume that copycat services will rise. Mitigation requires a shift from password-based security to phishing-resistant authentication.

1. Implement FIDO2/WebAuthn: This is the single most effective control against AiTM. FIDO2 keys (like YubiKeys) cryptographically verify the origin of the request, preventing a reverse proxy from relaying the authentication successfully.
2. Conditional Access Policies (CAP): Enforce strict location-based and device-based policies. If a user logs in from a new device or unfamiliar location, require step-up authentication or block access entirely.
3. Number Matching: For MFA solutions that support it (like Microsoft Authenticator), enable Number Matching. This adds a layer of friction that makes automated AiTM tools less effective.
4. Email Authentication: Ensure strict SPF, DMARC, and DKIM policies are in place to prevent the initial phishing email from reaching the user's inbox.

Executive Takeaways

The dismantling of Tycoon 2FA proves that public-private partnerships can disrupt the cybercrime economy. However, the "as-a-service" model is resilient. As long as there is demand for easy credential theft, new kits will emerge. Security leaders must prioritize Phishing-Resistant MFA (FIDO2) and invest in threat hunting capabilities that detect AiTM behaviors rather than just relying on credential alerts.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub