Look for behavioural anomalies rather than only bad domains or file signatures. Cloud-hosted lures, bot-blocking responses, unusual redirect chains, and mismatches between sender identity and request context are stronger indicators than a single malicious indicator. If the page is designed to look normal to scanners, the detection model must evaluate the interaction pattern.
How to spot phishing kits that evade static scanners
Static scanners are easiest to beat when the kit is built to look harmless at rest and only reveals itself during interaction. The practical shift is from file- or URL-only detection to behaviour-based analysis: watch how the lure responds, what it redirects to, and whether the page behaves differently for scanners, bots, or real users.
What static evasion looks like in practice
Phishing kits that bypass static checks often use cloud-hosted infrastructure, short-lived pages, or conditional content delivery. They may serve a benign page to a crawler, block headless browsers, or hide the credential capture flow behind multiple redirects and anti-bot checks. The page may appear ordinary until a real browser session follows the expected path.
That means defenders should treat a mismatch between the visible landing page and the underlying interaction path as a signal. If the sender, URL, or file looks innocuous but the session changes after a click, form submission, or cookie exchange, the kit is probably making decisions in real time instead of presenting a fixed payload.
One useful way to think about this is to look for phishing kit behaviour seen in the Twilio 0ktapus breach 2022, where the kit pattern mattered more than any single static indicator. Similar evasive kits often borrow the same playbook: normal-looking first contact, then selective delivery of the credential-harvesting flow once the target context looks genuine.
Signals that are stronger than a single bad indicator
The best signals are those that survive simple obfuscation. Cloud-hosted lures that rotate domains, redirect chains that only complete under certain user agents, and bot-blocking pages that change content based on IP reputation or browser features all point to a kit designed for live discrimination. These are harder to fake away than a single malicious domain or hash.
Another strong signal is context mismatch. If a message claims to be from one identity but the landing page, headers, TLS behaviour, or redirect destination suggest a different origin, the kit may be stitched together from multiple services to reduce scanner visibility. That mismatch is often more telling than the appearance of the page itself.
Where identity flow is involved, compare what the request claims to be with how the response behaves. A page that starts as a generic brand page, then shifts to a consent prompt, login form, or token relay only after the right interaction is often trying to evade static reputation checks. CoPhish OAuth phishing via Copilot Studio is a useful reminder that the abuse path can hinge on interaction flow, not just the presence of a malicious domain.
How to build detection that catches the interaction pattern
Static scanning still has value, but it should feed a broader detection pipeline rather than act as the final decision point. Run samples in an instrumented browser, capture redirects, compare behaviour across user agents, and record whether the page changes after cookies, JavaScript execution, or form submissions. If the content is conditional, the detection system needs to observe the condition, not just the page source.
It also helps to correlate web telemetry with email and endpoint signals. A message that passes content filters but leads to a page that behaves differently in automation, or a page that appears benign until a browser context is established, should be escalated even when static reputation is clean. Mailchimp breach 2022 is a good reminder that phishing operations often succeed by abusing trust chains and support workflows, not by leaving obvious malware artefacts.
Risk and Threat Considerations
Phishing kits that evade static scanners increase dwell time because they delay detection until a real user interacts. That raises the chance of credential capture, session theft, or downstream account takeover, especially when the kit is designed to adapt to scanner behaviour and only expose the malicious flow to human targets.
Failure mechanism: The kit conditions its payload on runtime context, such as browser characteristics, cookies, redirect state, or IP reputation, so a scanner sees a harmless front page while the victim sees the credential-harvesting path.
Impact: Defenders miss the campaign at intake, users are routed to a live capture page, and the attacker gains more time to collect credentials or session material before blocklists or signatures catch up.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Static-evasive kits are phishing delivery and credential capture. |
| T1036 — Masquerading | Kits hide malicious intent behind benign-looking pages and flows. | |
| T1090 — Proxy | Redirect chains and hosted relays are common evasion and routing patterns. | |
| Recommendation — Map observed kit behaviour to phishing techniques and tune detections for delivery, lures, and credential capture. Hunt for masquerading patterns where benign presentation hides an active credential or token theft flow. Inspect redirect infrastructure and relays for intermediary infrastructure that conceals the final phishing destination. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Behaviour-based detection depends on observing runtime interaction patterns. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Redirects, bot gating, and session anomalies need review across logs and traces. | |
| Recommendation — Instrument runtime monitoring to detect conditional behaviour that static scans miss. Correlate web, email, and endpoint logs to surface multi-step phishing activity. | ||
Practitioner Guidance
What to prioritise: Prioritise dynamic detonation for anything that looks benign at rest but shows redirects, browser gating, or brand impersonation. A clean static verdict should not override suspicious runtime behaviour.
What to verify: Verify the full interaction chain, not just the first URL. Capture the redirect sequence, page changes after execution, and any differences between headless and real-browser outcomes before you trust a “clean” result.
Practitioner takeaway: The decisive question is not “does it look malicious in static content?” but “does it behave maliciously when a real user reaches it?”