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

Common signs include self hosted bot checks, pixel accurate login flows, custom session handling, live field capture, and infrastructure that changes per target. In this case, certificate transparency logs exposed many related subdomains, and some looked like internal test traffic. Those operational traces often reveal more than the phishing page itself.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	Proxy phishing often steals cookies, tokens, and session material.
	NHI-03 — Session and Token Lifecycle	Live relay attacks depend on replayable sessions and weak token expiry.
Recommendation — Harden token handling and rotate exposed session material quickly. Enforce short-lived sessions and invalidate tokens after suspicious reuse.
MITRE ATT&CK	T1557 — Adversary-in-the-Middle	Custom reverse proxies are designed to intercept and relay interactive sessions.
Recommendation — Hunt for intermediary interception patterns and relay-based session theft.
CIS Controls v8	5.1 — Establish and Maintain an Inventory of Accounts	Phishing success becomes more dangerous when stolen access is not rapidly identified.
Recommendation — Maintain visibility into accounts so abnormal logins can be triaged fast.
NIST SP 800-63	5.2.7 — Phishing Resistance	The proxy-relay model targets authentication flows that can be intercepted or replayed.
Recommendation — Prefer phishing-resistant authenticators for high-value access paths.
NIST CSF 2.0	DE.CM — Continuous Monitoring	CT log spikes, host churn, and unusual login behaviour are detection signals here.
Recommendation — Monitor for infrastructure churn and anomalous authentication activity.

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.