How can defenders detect malicious use of Modlishka?

What Malicious Modlishka Activity Looks Like in a Live Environment

Modlishka is a reverse-proxy phishing kit, so defenders are usually looking for evidence that the victim’s browser is being proxied through an attacker-controlled host rather than interacting directly with the real service. That means the visible signs often show up in the browser, the identity provider logs, and the session trail, not just in a single malicious URL.

One practical way to think about detection is to correlate the login sequence with the network path. A successful sign-in that is preceded by an unfamiliar domain, an oddly branded lookalike page, or a sudden shift from legitimate authentication to a proxied flow is more suspicious than a simple credential-entry event. The same is true when MFA succeeds but the resulting session behaves as if it were replayed elsewhere.

Because these kits are designed to capture and reuse live session material, defenders should treat inconsistent session behavior as a clue. That includes MFA completion followed by a login from an unusual geography, device profile, or user agent, especially when the user later reports that they never completed a normal browser sign-in. NHIMG’s AiTM Phishing Guide covers the broader reverse-proxy phishing pattern that Modlishka belongs to.

Signals That Separate Modlishka From Generic Phishing

Generic phishing often ends with stolen credentials. Modlishka-style attacks go further by relaying the authentication exchange in real time, so defenders need indicators of proxying and session theft rather than only indicators of credential capture. That makes domain analysis, authentication telemetry, and post-login activity more important than page content alone.

Look for domains that are newly registered, poorly related to the target brand, or structurally inconsistent with the legitimate service. Also watch for authentication events where the browser fingerprints, IP reputation, or device posture do not line up with the user’s normal pattern. If the account enters a valid session immediately after an MFA challenge from a suspicious path, the question is no longer whether credentials were typed, but whether the session was hijacked in transit.

From a detection standpoint, unusual session continuation is often more useful than a single suspicious login event. Sudden token reuse, repeated authentication from multiple locations in a short window, or post-authentication activity that diverges from the user’s normal workflow can all indicate that the attacker is relaying the session through an intermediate proxy. MITRE ATT&CK Enterprise Matrix is useful for mapping those post-compromise behaviors to credential access and session abuse patterns.

How to Validate Suspicion Without Overreacting

Detection works best when teams validate suspicion with multiple weak signals instead of waiting for one perfect indicator. A suspicious login page, followed by a successful MFA event, followed by anomalous session context is a stronger case than any one of those events alone. That matters because users will often complete the flow normally from their point of view, even though the proxy is capturing the authentication exchange behind the scenes.

Review the sign-in record for mismatched origin data, then check whether the session persists beyond what the user expects or is used from a different network path immediately after authentication. If you have device telemetry, compare the login against endpoint state, browser characteristics, and session age. In many cases, the most reliable confirmation comes from correlating identity logs with help desk reports that the user saw an unexpected sign-in prompt or a browser page that looked slightly off.

Where the environment supports it, conditional access and phishing-resistant MFA reduce the attacker’s ability to turn a captured login into a usable session. NIST SP 800-63 Digital Identity Guidelines is a useful reference point for stronger authenticators and phishing-resistant approaches, while NIST Cybersecurity Framework 2.0 supports the broader detect and respond workflow around identity events.

Practitioner Guidance

What to verify: Prioritise the full authentication sequence, not just the login event. A Modlishka detection effort should confirm whether the domain was suspicious, whether the session context changed after MFA, and whether the resulting token or cookie was reused from an unexpected location.

Decision rule: If the user completed MFA but the post-login session does not fit the user’s normal device, geography, or browser profile, treat it as likely session hijack until proven otherwise. That is the point to investigate token use, revoke active sessions, and review recent privileged actions.

What practitioners underestimate: The user may truthfully report that they “logged in successfully,” which can mislead teams into underestimating compromise. For Modlishka-style attacks, a normal-looking sign-in experience can still be the mechanism that delivers the attacker’s session.

Practitioner takeaway: The best detection strategy is to correlate suspicious domains, authentication anomalies, and post-login session behavior, because no single indicator reliably proves reverse-proxy phishing on its own.

Related resources from NHI Mgmt Group

• How can defenders detect malicious use of TryCloudflare?
• How can defenders detect malicious use of Browser Exploitation Framework (BeEF)?
• How can defenders detect malicious use of Bginfo.exe?
• How can defenders detect malicious use of Csc.exe?