Performing Adversary In The Middle Phishing Detection

Performing Adversary-in-the-Middle Phishing Detection

Overview

Adversary-in-the-Middle (AiTM) phishing attacks use reverse-proxy infrastructure to sit between the victim and the legitimate authentication service, intercepting both credentials and session cookies in real time. This allows attackers to bypass multi-factor authentication (MFA). The most prevalent PhaaS kits in 2025 include Tycoon 2FA, Sneaky 2FA, EvilProxy, and Evilginx. Over 1 million PhaaS attacks were detected in January-February 2025 alone. These attacks have evolved from QR codes to HTML attachments and SVG files for link distribution.

When to Use

Trigger phrases:

• "performing adversary in the middle phishing detection"

• "Detect and respond to Adversary-in-the-Middle (AiTM) phishing attacks that use r"

• When conducting security assessments that involve performing adversary in the middle phishing detection

• When following incident response procedures for related security events

• When performing scheduled security testing or auditing activities

• When validating security controls through hands-on testing

Prerequisites

• Azure AD / Entra ID Conditional Access policies
• SIEM with authentication log ingestion (Azure AD sign-in logs)
• Web proxy with SSL inspection and URL categorization
• Endpoint Detection and Response (EDR) solution
• FIDO2/phishing-resistant MFA capability

Key Concepts

This section covers key concepts for performing adversary in the middle phishing detection.

• Ensure all prerequisites are met before proceeding
• Follow the documented workflow steps in sequence
• Record results and any anomalies encountered during this phase

How AiTM Works

1. Victim receives phishing email with link to attacker-controlled domain
2. Attacker domain runs reverse proxy that mirrors legitimate login page
3. Victim enters credentials on proxied page; credentials captured in transit
4. Reverse proxy forwards credentials to real authentication service
5. MFA challenge sent to victim; victim completes MFA on proxied page
6. Attacker captures session cookie returned by legitimate service
7. Attacker replays session cookie to access victim's account without MFA

Major AiTM Kits (2025)

Detection Indicators

• Authentication from unusual IP not matching user profile
• Session cookie reuse from different IP/device than authentication
• Login page served from non-Microsoft/non-Google infrastructure
• CDN requests to legitimate auth providers from phishing domains
• Impossible travel between authentication and session usage

Workflow

# Example: IOC detection
import re

IOC_PATTERNS = {
    "ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
    "domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",
    "hash_md5": r"\b[a-f0-9]{32}\b",
    "hash_sha256": r"\b[a-f0-9]{64}\b",
}

def extract_iocs(text: str) -> dict:
    return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}

1. Isolate the sample — ensure the malware is in a sandboxed environment with no network access
2. Record file metadata — hash the sample and note file type, size, and compile timestamp
3. Static analysis — examine strings, imports, and disassembled code without execution
4. Dynamic analysis — execute in a monitored sandbox and record behavior (file, registry, network)
5. Document IOCs — extract indicators of compromise and write the analysis report

Step 1: Deploy Phishing-Resistant MFA

• Implement FIDO2 security keys or Windows Hello for Business for high-value accounts
• Configure Conditional Access to require phishing-resistant MFA for admins
• Enable certificate-based authentication where possible
• Disable SMS and voice MFA for privileged accounts
• AiTM cannot intercept FIDO2 because authentication is bound to origin domain

Step 2: Configure Conditional Access Policies

• Require compliant/managed device for sensitive application access
• Block authentication from anonymous proxies and Tor exit nodes
• Enforce token binding to limit session cookie replay
• Configure continuous access evaluation (CAE) for real-time token revocation
• Implement sign-in risk policies that require re-authentication for risky sign-ins

Step 3: Build AiTM Detection Rules

• Alert on sign-in followed by session from different IP within 10 minutes
• Detect authentication where proxy IP does not match user's expected location
• Monitor for impossible travel patterns in session usage
• Alert on inbox rules created immediately after authentication (common post-compromise)
• Detect new MFA method registration from suspicious sign-in

Step 4: Monitor Web Proxy for AiTM Infrastructure

• Log and analyze DNS queries to newly registered domains
• Detect connections to known PhaaS infrastructure IPs
• Alert on authentication page backgrounds loaded from legitimate CDNs through proxy domains
• Monitor for SSL certificates issued to domains mimicking corporate login pages
• Block access to known EvilProxy/Evilginx infrastructure via threat intelligence

Step 5: Implement Post-Compromise Detection

• Alert on mailbox forwarding rules created after suspicious authentication
• Detect OAuth app consent after AiTM sign-in
• Monitor for email sending patterns indicating BEC follow-up
• Alert on SharePoint/OneDrive mass download after session hijack
• Track lateral movement from compromised account

When NOT to Use

• You don't have explicit written authorization to test
• Task is about defense/detection, not offense (use detection skills)
• You need to implement security controls (use implementing-* skills)
• Task requires compliance auditing (use auditing-* skills)
• You're investigating an incident (use incident response skills)
• Target is out of scope for your engagement
• Task is about vulnerability scanning only (use scanning tools)

Red Flags

• Performing actions without explicit written authorization from the asset owner
• Testing against production systems without a defined scope and rules of engagement
• Analyzing malware on a machine connected to the production network
• Failing to isolate the analysis environment from the internet
• Executing samples without proper containment (VM, sandbox)

Verification

• All steps executed successfully against a test environment before production use
• Output documented with screenshots or logs demonstrating expected behavior
• Sample hash recorded and verified (MD5, SHA-1, SHA-256)
• Analysis environment confirmed isolated from production network
• Indicators of compromise (IOCs) extracted and documented

Tools & Resources

• Microsoft Entra ID Protection: Risk-based Conditional Access
• Azure AD Sign-in Logs: Authentication event analysis
• Okta ThreatInsight: AiTM proxy detection at IdP level
• Sekoia TDR: AiTM campaign tracking and intelligence
• Evilginx (defensive): Understanding attack mechanics for detection

Validation

• Phishing-resistant MFA blocks AiTM session capture in test scenario
• Conditional Access denies session replay from different device/IP
• SIEM alerts fire on simulated AiTM sign-in patterns
• Web proxy blocks connections to known PhaaS infrastructure
• Post-compromise rules detect inbox rule creation after suspicious auth

Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality

Anti-Rationalization Table