How should security teams detect browser attacks when domains and URLs rotate constantly?

Why rotating domains change the detection problem

When attackers rotate domains and URLs, they are trying to make infrastructure indicators age out faster than defenders can block them. That makes static blocklists fragile: by the time a bad domain is known, the same campaign may already be on the next one. Detection has to anchor on the browser activity that the attacker still needs to perform, not on the address that happens to host it.

This is a technique-centric problem. The web location can change, but the attack still has to deliver content, execute script, redirect the victim, and often solicit input. Those steps create a more durable signal than a hostname alone, especially when the campaign uses disposable infrastructure or compromised sites.

Teams also need to separate benign site churn from malicious rotation. Fast-changing URLs are common in legitimate web flows, so the real task is to identify combinations of redirect chains, script behaviour, form interactions, and credential collection that form an attack pattern rather than a one-off navigation event.

What browser telemetry remains stable across domain rotation

Browser-focused hunting works best when it records what the page does after load. Redirect sequences, unexpected script execution, DOM changes, fake login prompts, clipboard or keystroke capture, and submission of entered credentials are all more durable than the originating domain. If the same behaviour appears across many rotating URLs, you have evidence of a common technique.

Behavioural evidence is especially useful when the attacker chains multiple hops. A campaign may start on a clean-looking landing page, redirect through several intermediates, and end on a credential harvest page. Infrastructure changes at each hop, but the operational pattern remains visible if your telemetry captures navigation, script and form events together.

Detection should therefore emphasise page semantics. A login page that arrives through a suspicious redirect chain, loads obfuscated script, and immediately asks for credentials is far more interesting than a single isolated domain flag. That is the kind of pattern hunting that survives rapid infrastructure churn.

How to operationalise technique-based browser hunting

Security teams should build detections that correlate browser activity with post-load behaviour, not just URL reputation. Useful signals include repeated redirect patterns, scripts loaded from unrelated origins, form submissions to unexpected endpoints, and pages that imitate authentication flows without a legitimate session context. In practice, that means enriching browser logs with the surrounding sequence, not treating each page view as an isolated event.

Static vs dynamic secrets is a helpful analogy here: just as short-lived credentials reduce dependence on a fixed secret, technique-based detection reduces dependence on a fixed domain. The point is to hunt for the repeated behaviour that survives infrastructure turnover.

For operational triage, start with pages that combine redirects, script execution, and credential entry, then score them higher when the destination changes frequently or the same behavioural chain appears across many hosts. That gives analysts a stable hunt pattern even when the attacker rebrands the delivery site every few hours.

Risk and Threat Considerations

Attackers rotate domains to outrun reputation systems, sinkholing, and manual blocklist updates. If defenders rely too heavily on infrastructure-only indicators, they risk missing the same campaign as it reappears on new hosts, especially when the malicious page is short-lived and designed to disappear before the next control cycle.

Failure mechanism: The defender keys on domains and URLs instead of the browser technique, so each new host looks like a new event rather than a continuation of the same attack chain. This creates blind spots in detection, slows hunting, and weakens correlation across otherwise related sessions.

Impact: Credential theft, account takeover, and downstream session abuse can proceed even while individual domains are being blocked. The organisation sees churn in infrastructure but not the repeated interaction pattern that actually identifies the threat.

Practitioner Guidance

What to prioritise: Correlate redirect chains, script execution, and credential-entry events into a single huntable pattern. A host reputation hit is useful, but it should not be the deciding signal when the page behaviour is already suspicious.

What to verify: Confirm that telemetry captures the full browser sequence, including destination changes, external script loads, and submission endpoints. If you only log the final URL, you will miss the path that proves the technique.

Common mistake: Treating every rotating domain as a separate problem. The better question is whether the same malicious interaction model is showing up under different infrastructure.

Practitioner takeaway: The most resilient browser detection logic is behaviour-based, because attacker infrastructure can be swapped quickly but the required interaction pattern usually cannot.

Related resources from NHI Mgmt Group

• How should security teams detect phishing when domains rotate quickly?
• How should security teams detect browser-based copy-paste attacks before they execute locally?
• How should security teams detect and respond to browser-based identity attacks before attackers turn stolen credentials into account takeover?
• How should security teams detect polymorphic email attacks that keep changing wording, sender details, and domains?