Modlishka and MFA-bypass phishing: what awareness teams should simulate safely

Modlishka is an important name in MFA-bypass phishing discussions, but it is not a normal foundation for employee awareness training. It is a reverse-proxy phishing tool, widely known in security circles because it helped demonstrate how convincing phishing flows can interact with modern authentication and multi-factor prompts.

That lesson matters. The operational tool category does not.

Security teams should absolutely train employees on MFA-bypass risk, suspicious login prompts, push fatigue, QR-code login flows, OAuth consent prompts, and helpdesk impersonation. But they should do that through controlled simulations that avoid credential capture, avoid session material, respect privacy, and produce useful behavior data.

The useful takeaway from Modlishka is not "run reverse-proxy phishing against employees." The useful takeaway is "MFA changes phishing risk, but it does not eliminate the need for awareness, reporting, and verification habits."

Why Modlishka still has name recognition

Modlishka has strong name recall because it sits at the intersection of authentication, phishing, and MFA. Public GitHub activity shows the project remains visible, with thousands of stars and recent repository updates. It is not an abandoned old toolkit in the same category as some legacy phishing frameworks.

That makes the content angle different.

For GoPhish, Phishing Frenzy, King Phisher, or Simple Phishing Toolkit, the buyer question is often "is this still maintained enough to use?" For Modlishka, the better question is:

How should an awareness program cover MFA-bypass phishing without turning training into credential interception?

That is a real security question. It deserves a safer answer.

MFA reduced risk, but did not remove phishing

Multi-factor authentication makes many attacks harder. It reduces the value of password-only compromise and gives organizations a stronger baseline. But employees can still face risky situations:

• fake login prompts after a convincing email
• push approval fatigue
• helpdesk calls that pressure MFA reset or enrollment
• QR-code login lures
• OAuth consent screens that request excessive access
• suspicious device registration prompts
• supplier or document workflows that lead to unexpected authentication

Awareness training should help employees recognize those moments and report them quickly. It should not teach them that every MFA prompt is safe, or that a familiar-looking login page is trustworthy by default.

Public security-awareness guidance from government agencies and national cyber centers usually lands on the same practical baseline: the defensive behavior is verification and reporting, not proving how realistic an attack can be.

Reverse-proxy tooling is not awareness software

Reverse-proxy phishing tooling belongs in specialist security testing with explicit authorization, strict scope, legal review, and experienced operators. Employee awareness training has a different purpose.

A normal awareness program should optimize for:

• safer behavior under realistic pressure
• employee trust
• privacy-conscious measurement
• repeatable cadence
• manager-safe reporting
• useful coaching
• evidence that leadership can understand

It should not normalize capturing passwords, MFA codes, tokens, or sessions as part of routine training.

Even when a simulation teaches MFA-bypass risk, it can stop before secret collection. It can show an unexpected prompt, measure whether the employee reports it, and then provide immediate feedback. That is enough to teach the behavior without creating unnecessary data risk.

What to simulate instead

The safest MFA-awareness scenarios focus on decision points, not secret capture.

Useful examples include:

• an unexpected login prompt after a file-sharing email
• a push notification that arrives without a user-initiated login
• a helpdesk-style message asking the employee to "confirm" MFA enrollment
• a QR-code sign-in flow shown as a screenshot or safe landing page
• an OAuth consent prompt asking for broad mailbox or document access
• a supplier portal invite that uses a lookalike domain

The goal is to train questions employees can actually use:

• Did I initiate this login?
• Is this the normal domain or application?
• Does this request fit the business context?
• Should I report this before interacting further?
• Is there an approved verification path?

That is how MFA-bypass awareness becomes practical rather than theatrical.

Do not collect real secrets

The clearest safety boundary is simple: do not collect real passwords, MFA codes, recovery answers, session cookies, or tokens in employee awareness campaigns.

Measure behavior without harvesting secrets:

• delivered
• opened
• clicked
• suspicious prompt reached
• report submitted
• feedback viewed
• microtraining completed
• repeat risky interaction reduced

If a landing page is needed, use a safe page that explains the risk and stops before the sensitive action. The employee should leave the exercise understanding what to do next time, not wondering whether security tricked them into exposing something real.

For a closely related MFA-safety angle, AutoPhish's guide to CredSniper alternatives for safe MFA phishing awareness is a better model than trying to mimic an offensive tool workflow.

Build the program around reporting

MFA-bypass simulations should reward reporting. That is the behavior that helps the security team respond to real attacks.

A useful program should answer:

• How quickly did employees report suspicious login prompts?
• Which departments reported before clicking?
• Which scenarios created confusion?
• Did employees use the approved reporting channel?
• Did repeat exposure improve the behavior?
• Which prompts need clearer internal guidance?

This is where phishing awareness becomes operationally useful. It gives security teams evidence that can improve controls, not just a click-rate chart.

For reporting design, AutoPhish's guide to phishing simulation reporting pairs well with MFA-focused campaigns.

Where red-team testing fits

There is still a place for specialist testing. A mature organization may run authorized red-team or purple-team exercises that include adversary-style authentication scenarios. Those exercises should be scoped separately from employee awareness:

• fewer participants
• explicit approval
• defined legal and privacy review
• strict data handling
• experienced operators
• clear incident-response integration
• post-exercise cleanup

That is a different workflow than normal awareness training for a broad employee population.

Do not blur the two. Awareness programs need trust. Red-team exercises need controlled adversary realism. Mixing them carelessly weakens both.

What a safer platform should provide

If your team is searching for Modlishka because MFA-bypass phishing is on the risk register, compare platforms on their ability to simulate the theme safely.

Look for:

• MFA and login-prompt scenario support without secret capture
• safe landing pages and screenshots
• role-based targeting for IT, finance, HR, executives, and assistants
• reporting workflow measurement
• privacy controls and retention limits
• manager-safe aggregated reporting
• clear audit evidence
• campaign approval controls
• automatic feedback and microtraining

The right alternative is not "a less offensive reverse proxy." It is an awareness platform that can teach the same defensive decision points without creating unnecessary operational risk.

FAQ

Is Modlishka abandoned?

No. Public repository signals show Modlishka remains visible and has recent activity. The reason not to use it for normal employee awareness is not abandonment. It is tool fit: reverse-proxy phishing tooling is not the same as a governed awareness platform.

Should employees be trained on MFA-bypass phishing?

Yes. Employees should understand suspicious login prompts, push fatigue, OAuth consent risk, QR login lures, and helpdesk pressure. The training should avoid real credential or token capture.

Can phishing simulations cover MFA without collecting secrets?

Yes. A simulation can show a suspicious prompt, measure whether the employee reports or continues, and provide feedback before any real secret is entered. That is usually the safer awareness model.

What is a safer Modlishka alternative for awareness training?

Use a phishing simulation platform that supports MFA-themed scenarios, safe landing pages, privacy-aware reporting, and follow-up training. Do not treat an offensive reverse-proxy tool as routine awareness software.

Train the risk, not the attack chain

Modlishka is a useful reminder that authentication defenses are part of a human workflow. MFA helps, but employees still need to recognize suspicious prompts and report them.

The awareness goal is not to recreate an attack chain. It is to build safer habits around login prompts, approvals, consent screens, and verification.

Sign Up