What Is Modlishka?

Modlishka is an open-source reverse HTTP(S) proxy tool designed for penetration testing that enables Adversary-in-the-Middle (AiTM) attacks by transparently proxying authentication flows and capturing credentials and session tokens without requiring client-side certificate installation. Originally released in January 2019 by Polish security researcher Piotr Duszynski (drk1wi), Modlishka was the first publicly released research tool to demonstrate a novel AiTM technique capable of bypassing many common 2FA implementations (Duszynski, 2019). Written in Go, the tool is now widely used by both red teamers and cybercriminals for 2FA bypass and credential harvesting despite its intended legitimate security research purpose.

How Does Modlishka work?

Transparent Reverse Proxy

Modlishka acts as MITM between victim and legitimate website, with victim requests forwarded to the real site and responses relayed back according to GitHub documentation and ProCheckup. Unlike traditional phishing kits that require attackers to build and maintain static HTML clones, Modlishka requires no website templates: operators simply point the tool at the target domain and in most cases the proxying is handled automatically (GitHub, 2019). Credential capture via regex uses regex patterns to identify and extract login credentials from authentication requests and responses as they pass through the proxy.

Architecture and Plugin System

Modlishka is implemented in Go, making it cross-platform compilable and deployable on any system where Go is available. The architecture follows a stateless design that can be scaled to handle arbitrary amounts of traffic through a DNS load balancer according to its official documentation. The tool features a modular plugin system that supports pattern-based JavaScript payload injection and extensibility, allowing operators to customize behavior for specific targets. Key configuration is managed through JSON configuration files and command-line flags, with plugins handling tasks such as automatic TLS certificate generation via Let's Encrypt (autocert plugin) and credential logging. The Go-based implementation avoids slow regex replacement operations used by older tools, contributing to faster proxy performance under load.

Session token hijacking intercepts and captures authenticated session cookies, enabling attackers to use stolen cookies to access victim accounts without knowing passwords. The 2FA bypass process follows seven steps: attacker lures victim to malicious domain running Modlishka proxy, victim enters username and password which passes through to legitimate site, legitimate site sends 2FA challenge to victim via SMS, email, or app, victim enters 2FA code into Modlishka proxy page, Modlishka captures the code and relays it to legitimate site, legitimate site authenticates victim and returns session cookie, Modlishka captures the authenticated session cookie, and attacker now has valid session without knowing victim's password.

TLS encryption handling generates self-signed or attacker-controlled certificates to encrypt victim-to-proxy connection, preventing detection via HTTPS inspection. The tool can also leverage its autocert plugin to automatically obtain valid TLS certificates from Let's Encrypt, reducing certificate-related browser warnings that might alert victims (Duszynski, 2019). Multi-domain support means single proxy instance can transparently handle traffic to multiple destination domains without installation of additional certificates on client. This capability enables what Duszynski termed "Client Domain Hooking," a technique described in the accompanying research paper that allows a single phishing domain to seamlessly serve content from multiple backend origins.

How Does Modlishka differ from other tools?

Why Does Modlishka matter?

Open-source availability has made it widely adopted among both red teamers and cybercriminals since 2019 according to ProCheckup and Code42. Multiple forks and variants exist including Modlishka-Phishing-NG by slowmistio, improvements by An0nUD4Y, and vitalyford variants. Used extensively in penetration testing engagements by authorized security professionals. Abused by attackers as foundation for advanced phishing campaigns in 2024-2025. Part of ecosystem of phishing proxies that Proofpoint reports were used in over 1 million attempted account takeovers in early 2025 alongside EvilProxy, Frappo, and Muraena. Tutorials and guides widely available on security blogs make deployment accessible to non-technical attackers.

What Are the limitations of Modlishka?

Certificate pinning means mobile apps and modern browsers with certificate pinning cannot be bypassed because victims must accept untrusted certificate warnings. Manual configuration unlike commercial kits like Starkiller requires manual regex configuration for each target site, with updates breaking credentials capture. No automation lacks automated credential extraction, requiring attackers to manually define extraction patterns per target. Detection risk occurs because self-signed certificates create HTTPS warnings and legitimate sites may use HSTS headers preventing downgrade attacks. Skill requirement means it requires more technical knowledge than point-and-click commercial kits, with configuration errors leading to failed attacks. Maintenance burden exists because original drk1wi repository appears to have limited recent updates, and community-maintained forks may have security issues. Limited monitoring provides no real-time dashboard compared to commercial alternatives, requiring attackers to review logs after fact. Session timeout means captured session cookies have limited validity period, and if victim changes password, stolen cookie becomes worthless.

How Can you defend against Modlishka?

Strict certificate pinning implements certificate pinning in mobile apps and desktop clients to prevent MITM proxy attacks. Hardware security keys use FIDO2/U2F hardware keys that cannot be relayed through proxies. Behavioral analysis monitors for sessions accessing accounts from unexpected locations or devices with unusual patterns because proxy relays often lack user's normal behavior. Email-based phishing detection deploys advanced email security to identify suspicious senders before users click links. User education trains users to verify URLs in address bar, check for certificate warnings, and recognize suspicious email senders. Device fingerprinting rejects authentication from devices with unusual fingerprints because Modlishka relays create detectably different TLS fingerprints. Geo-velocity checks flag logins from geographically impossible locations in short timeframes when attacker relays from different location than victim. Session analysis monitors for sessions with inconsistent HTTP headers, User-Agent strings, or TLS patterns. Re-authentication on sensitive actions requires step-up authentication for password changes, account transfers, or access to sensitive data.