Lesson 1.1: Starkiller Phishing Suite Uses AitM Reverse Proxy to Bypass Multi-Factor Authentication

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Starkiller Phishing Suite Uses AitM Reverse Proxy to Bypass Multi-Factor Authentication! Over the next 45 minutes, we will explore how a new class of phishing tool makes traditional multi-factor authentication (MFA) useless, and what you can do about it.

But first, let me tell you about Marcus Webb.

It's 10:15 on a Tuesday in October. Marcus Webb, a finance manager at a mid-sized manufacturing firm in Birmingham, is reviewing a quarterly report. The office hums with the low murmur of keyboards and the faint smell of coffee. His phone buzzes with a calendar alert for a vendor payment review meeting he doesn't recognise.

A minute later, an email arrives from what appears to be the company's IT support desk. The subject is 'Urgent: Action Required for Your Microsoft 365 Account'. The email is clean, uses the correct logo, and references the unexpected meeting invite. It asks him to click a link to confirm his identity and prevent account suspension. It feels slightly off, but the timing is persuasive.

Marcus clicks the link. A perfect replica of the company's Microsoft login page loads. He enters his username and password. He's prompted for MFA. He approves the push notification on his authenticator app. The page spins for a moment, then logs him into his genuine Microsoft 365 portal. Everything seems normal. But in that brief moment, everything was stolen.

This is the story of a modern phishing attack. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: The End of MFA as We Knew It

For years, we've treated multi-factor authentication like a vault door. A password is a key, but MFA is the deadbolt. Attackers like Starkiller have found a way to stand beside you, watch you unlock the door, and then simply walk in behind you.

What is an Adversary-in-the-Middle (AitM) Attack?

An AitM attack doesn't try to break MFA; it tricks you into giving it away. The attacker acts as a malicious proxy between the victim and the real service, like a concierge who intercepts your mail.

When you enter your credentials on the fake site, the proxy forwards them to the real service in real-time. When the real service sends an MFA challenge, the proxy passes it to you. Your approval is then sent back through the proxy to the real service, completing the login. The attacker captures your session cookies, granting them full access without needing your password or MFA code again.

This makes one-time codes, push notifications, and even some hardware tokens ineffective. You are authenticating the attacker's session, not your own.

The Phishing-as-a-Service Model

Tools like the Starkiller Phishing Suite commoditise this advanced attack. They are sold or rented on criminal forums, lowering the barrier for entry. Attackers no longer need deep technical skill; they need a credit card and a target list.

These kits often come with management dashboards, email templates, and automated infrastructure setup. The business model is subscription-based or one-time purchase, making sophisticated phishing a scalable criminal enterprise.

DORA Article 5-17 DORA requires financial entities to have strong ICT risk management. Relying solely on MFA for access control, without understanding its failure modes against AitM attacks, does not meet the requirement for resilient security measures.

ISO A.8.2 ISO 27001 mandates security awareness training. Training that only warns about suspicious links, without explaining how modern kits bypass MFA, leaves an organisation exposed to credential theft.

Content Section 2: Inside the Attack: How Starkiller Works

Understanding the mechanics reveals why it's so effective. Let me show you exactly how Marcus was compromised, step by step.

The Attack Flow

Step 1: The Lure. Marcus receives a convincing email, often leveraging a current event or internal process (like a meeting invite). The link points to an attacker-controlled server.

Step 2: The Proxy Setup. When Marcus clicks, the Starkiller server spins up a reverse proxy configured for Microsoft 365. It generates a unique phishing URL for him.

Step 3: Credential Harvesting. Marcus sees a perfect clone of the login page. His keystrokes are sent to the proxy, which immediately forwards them to Microsoft. From his perspective, any typos or password errors work as normal.

Step 4: MFA Interception. Microsoft sends an MFA request. The proxy displays this to Marcus. When he approves it on his phone, that approval is sent via the proxy to Microsoft.

Step 5: Session Cookie Theft. The proxy now has a valid, authenticated session cookie from Microsoft. It can use this cookie to access Marcus's account directly, often while he is still logged in, unaware.

Key Technical Components

The reverse proxy is the heart of the attack. Open-source tools like Evilginx or Modlishka are often repackaged into kits like Starkiller. They handle the complex HTTP/S rewriting needed to make the fake site look real.

The kits also include 'fingerprinting' to avoid detection. They might check if the visitor is a known security researcher's IP address or a automated sandbox, showing a blank page to these visitors while displaying the phishing page to real targets.

Why Traditional Defences Fail

Notice what all of these methods have in common. They focus on preventing the theft of the *secret* (password, code). The AitM attack doesn't steal the secret for later use; it uses it immediately, in real-time, making those defences irrelevant.

Many common security controls are blind to this attack pattern. Here's how they are bypassed:

NIST PR.AC-7 NIST CSF PR.AC-7 calls for authentication commensurate with risk. If MFA can be bypassed in real-time, the authentication strength is effectively zero for this threat. Organisations need stronger, phishing-resistant MFA to meet this control.

NIS2 Article 21 NIS2 mandates appropriate risk management measures. Continuing to use MFA methods known to be vulnerable to real-time phishing, without additional compensating controls, fails to meet the requirement for state-of-the-art security.

Content Section 3: Seeing the Invisible: Detection Strategies

Marcus's computer knew something was wrong. The network traffic looked unusual. It just couldn't tell him. Here's what you can look for.

Network-Level Indicators

Unusual Redirect Chains: Look for login traffic that goes to an unknown domain before reaching the legitimate identity provider (like login.microsoft.com).

SSL/TLS Fingerprinting: The proxy software may have a distinct TLS handshake signature or use less common cipher suites. Tools can fingerprint these.

Geolocation Mismatches: A user in Birmingham logging in, with session activity suddenly appearing from an IP in a different country minutes later is a strong signal of session cookie theft and reuse.

Endpoint-Level Indicators

Process Creation: The user's browser may make connections to the phishing domain, but the proxy process on the attacker's server is the one communicating with Microsoft. On the endpoint, you only see the connection to the phishing site.

DNS Queries: A spike in DNS requests for new, randomly generated subdomains (a characteristic of some phishing kits) can be a precursor to an attack.

Identity Provider Signals

Impossible Travel: Microsoft Entra ID and other identity systems can detect 'impossible travel'—a login from the UK followed by a login from Eastern Europe two minutes later.

Session Token Anomalies: Monitor for session tokens being used from multiple, geographically disparate IP addresses simultaneously, or from known malicious infrastructure.

Conditional Access is Key: Policies that block logins from unfamiliar locations, untrusted devices, or require phishing-resistant MFA (like FIDO2 security keys) can stop the attack even after credentials are captured.

SOC2 CC6.1 SOC 2 requires logical access controls to protect assets. Detecting anomalous login sequences and session hijacking is part of monitoring those controls. Without monitoring for the specific patterns of AitM attacks, the control is not operating effectively.

GDPR Article 32 GDPR requires appropriate technical measures for security. Failing to implement or monitor for controls that can detect the bypass of authentication mechanisms could be seen as a lack of appropriate security, especially if a breach leads to unauthorised access to personal data.

Content Section 4: Building Your Compliance Evidence

Compliance isn't about ticking boxes; it's about proving you've built a defensible position. Think of it as the audit trail that shows you understood the threat and acted.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate that your ICT risk management considers advanced threats like real-time phishing that bypass MFA, and that you are training staff accordingly.

For ISO A.8.2 auditors... For ISO 27001 assessors, you can evidence that your security awareness training programme covers the limitations of traditional MFA and the need for phishing-resistant methods.

For NIST PR.AC-7 auditors... For NIST CSF reviewers, you can show you have assessed the strength of your authentication practices against specific adversary techniques (AitM) and are planning mitigations.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified (e.g., 'Schedule meeting with IAM team to discuss phishing-resistant MFA')

Conclusion

Let me tell you how Marcus's story ended.

The attackers used Marcus's session to access the finance system. They created a new, fraudulent vendor and approved a payment of £85,000. The money was gone before the afternoon was over. Marcus faced a disciplinary investigation. While he kept his job, the trust was broken, and the stress took a personal toll.

The organisation eventually implemented phishing-resistant FIDO2 security keys for the finance and executive teams. They deployed stricter Conditional Access policies and began monitoring for session cookie anomalies. The changes came after the loss, not before.

But it doesn't have to be your story. That's why we're here.

You should now understand how AitM phishing kits like Starkiller bypass MFA in real-time. You understand the technical flow of the attack and why traditional defences fail. You know key detection indicators at the network, endpoint, and identity layers. And you understand the compliance imperative to move towards phishing-resistant authentication.

Next, we'll explore Next, we'll explore Lesson 1.2: Detecting and Hunting for AitM Phishing Infrastructure. We'll look at how security operations teams can proactively find these attacks before the session cookies are stolen.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators (network redirects, TLS fingerprints, impossible travel) and immediate response steps (revoke sessions, require re-authentication) for AitM phishing attacks on a single page.
• Compliance Mapping Worksheet - Map your organisation's MFA and access controls to the specific DORA, NIST CSF, and ISO 27001 requirements relevant to mitigating AitM phishing threats covered in this lesson.
• Risk Assessment Template - Assess your organisation's exposure to AitM phishing based on user roles, MFA methods in use, and the sensitivity of accessible cloud applications.
• Further reading - Links to the Microsoft documentation on Conditional Access and phishing-resistant MFA, and the CISA guidance on implementing phishing-resistant MFA.

Starkiller Phishing Suite Uses AitM Reverse Proxy to Bypass Multi-Factor Authentication Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026