What are the signs that a phishing campaign is using a custom-built reverse proxy rather than a public toolkit?

What the traffic pattern reveals

A custom-built reverse proxy usually leaves behavioural traces that are broader than a single phishing page. The strongest indicators are not just the credential prompt, but the way the lure behaves under inspection: self-hosted bot checks, exact visual cloning, session state that survives navigation, and live capture of fields as the victim types. Those traits suggest the operator is mediating the session in real time rather than simply serving a static kit.

Infrastructure is another clue. Public kits tend to be reused at scale, while custom proxies often rotate per target, per campaign, or per lure domain. If certificate transparency logs show a cluster of related subdomains, short-lived hosts, or naming patterns that resemble staging and internal testing, that usually points to an operator managing their own relay layer rather than borrowing a commodity phishing panel.

One useful comparison is whether the site behaves like a one-way collection form or like a live interception point. When the page reflects the victim’s inputs immediately, preserves cookies or tokens across steps, and adapts to the target environment, the campaign is optimised for credential relay, session theft, or MFA bypass rather than simple harvesting.

Why custom proxies look different from public toolkits

Public kits are designed for scale and convenience, so they often leak their identity through repetition, template artefacts, and predictable hosting patterns. Custom reverse proxies are built to lower detection and increase success against specific targets, which means the operator invests in anti-analysis, environmental checks, and flow fidelity. The more the page behaves like the real service in motion, the more likely it is that the operator is relaying traffic rather than merely imitating a login screen.

That distinction matters because the reverse proxy sits in the middle of the session. If the victim’s browser is talking to an attacker-controlled relay, the attacker can pass through credentials, session cookies, and MFA outcomes in near real time. In practice, that means defenders may see a legitimate login succeed while the attacker silently takes over the session afterward. NHIMG’s Ultimate Guide to Non-Human Identities is useful background when you are tracing the broader secret and token lifecycle behind that kind of access abuse.

For phishing analysis, the practical question is not just “does it look real?” but “does it behave like a proxy with state?” If the answer is yes, the campaign is usually more dangerous than a standard credential harvester because it can defeat weaker MFA flows and reduce the time available to intervene.

Risk and Threat Considerations

Custom reverse proxies raise the stakes because they are built to preserve and relay authenticated sessions, not merely collect passwords. That makes them especially effective against phishing-resistant-looking but still relayable authentication paths, and it increases the chance that a single successful visit becomes a full account takeover rather than a one-time credential loss.

Failure mechanism: The attacker controls the page and the intermediary session path, so credentials, cookies, and authentication assertions can be forwarded in real time while the victim still believes they are interacting with the legitimate service. Bot checks and per-target infrastructure also help the operator avoid automated detection and mass takedown.

Impact: Defenders may observe a clean login event while the attacker inherits a live session, which shortens dwell time, complicates incident triage, and can expose downstream data or administrative actions before the compromise is noticed.

Practitioner Guidance

What to verify: Check whether the page’s behaviour changes with browser automation, headless inspection, or malformed navigation. A custom proxy often fails in subtle ways that a public kit would not, especially when the site must preserve state across redirects and token exchanges.

What to prioritise: Treat certificate transparency anomalies, short-lived lure domains, and internal-looking test names as high-value triage signals. Those traces often identify the operator’s infrastructure faster than content-based detectors do, especially when the phishing page itself is visually accurate.

Practitioner takeaway: The best indicator of a custom reverse proxy is usually not the phishing page alone, but the combination of session fidelity, per-target infrastructure, and operational residue that shows the attacker is actively brokering the login flow.

Related resources from NHI Mgmt Group

• What are the signs that a phishing campaign is using DLL sideloading to deliver malware?
• What are the signs that a phishing campaign is using an attacker-in-the-middle kit to steal session access?
• What are the signs that a phishing campaign is adapting to security controls rather than being shut down?
• What are the signs that a Google-based phishing campaign is using collaboration features as an attack channel?