Catching Redirect Chains with ANY.RUN’s In-Browser DOM Inspector

Introduction — why in-browser inspection matters for phishing triage

The first thing I want from phishing triage is not a prettier screenshot. I want the chain.

A final rendered page can look real and still hide the important part. By the time a sandbox finishes loading, the page may have already redirected multiple times, swapped out its form, hidden the original content, or changed behavior based on timing. If you only look at the end state, you usually learn where the victim landed, not how the lure worked.

Clear position: screenshots alone miss the chain, not just the page

My view is simple: screenshots are evidence, but they are not enough evidence.

For phishing work, the path matters more than the destination:

• the first URL shows the lure
• intermediate hops show infrastructure and intent
• DOM mutations show when the attacker changes the story
• network timing often shows whether the page was trying to evade analysis

That is why I care about tools that expose browser state while the page is still alive.

What the source report says about ANY.RUN’s new DOM inspection

A June 23, 2026 report says ANY.RUN added in-browser data inspection to expose phishing redirects and DOM changes. The interesting part is not the label. It is the workflow shift: the analyst can inspect what the browser saw while navigation, page mutation, and rendering were still happening.

I cannot verify the vendor’s exact UI wording from the material provided here, so I am treating the report as the source of record. But the technical direction is obvious enough: move from final screenshot analysis toward browser-state analysis.

What changed in the sandbox workflow

In-browser data view for DOM changes, redirects, and page mutations

The useful part of this feature is that it puts browser evidence next to the sample instead of burying it behind the final page. In practice, that means you can inspect:

• redirect hops
• live DOM updates
• form insertion or replacement
• script-driven page mutations
• timing between load and navigation

That is a better triage model because phishing pages are often built to be watched only briefly. The page you see at second ten may not resemble the page you saw at second one.

Why this is different from relying on a final rendered screenshot

A screenshot tells you what ended up on the screen.

A browser-state view tells you:

• what the page loaded first
• whether the page navigated before the DOM stabilized
• whether content appeared only after a script ran
• whether a login form was injected late
• whether the visible page was just a shell around something else

That difference matters because many phishing kits are designed to split the evidence across time. The lure is one thing, the landing page is another, and the credential capture form may only appear after a delay or a fingerprinting check.

How phishing redirect chains actually hide in plain sight

Meta refresh, JavaScript redirects, and delayed navigation

The simplest redirect chain is still common:

• HTTP 302 or 301 responses
• <meta http-equiv="refresh">
• window.location = ...
• location.replace(...)
• delayed redirects from setTimeout(...)

These are not exotic. They are popular because they work in browsers and can stall automation or split analysis across multiple hops.

A chain like this often looks harmless if you only inspect the final response. The abuse is in the sequencing.

Cloaked landing pages, form swaps, and content that mutates after load

Phishing pages do not always redirect immediately. Some wait for:

• a specific user agent
• a geolocation signal
• a time window
• a human interaction event
• a referrer or cookie check

Then they mutate the page:

• hide the initial lure
• swap a benign sign-in form for a credential harvester
• replace brand assets after a delay
• inject an iframe or overlay

The page source at load time and the DOM after script execution can be very different documents.

Where analysts usually lose visibility: timing, intermediate states, and hidden DOM nodes

The failure mode I see most often is overtrusting the endpoint state.

You land on the final URL, capture a screenshot, and move on. But the interesting evidence is usually in the intermediate states:

• the first hop may contain the attacker’s infrastructure
• the second hop may reveal a tracking or filtering service
• the live DOM may contain hidden fields or script blobs that were not in the initial HTML
• the page may only reveal its malicious behavior after a delay

If you do not track the transitions, you miss the structure of the attack.

A practical walkthrough for analysts

Start with the first URL, not the final landing page

If you get a suspicious link, begin with the original URL from the email, chat message, or browser artifact. Do not start from the final rendered domain unless that is all you have.

A good triage note should include:

• original URL
• timestamp first seen
• first response code
• each subsequent navigation target
• final destination domain
• any visible change in branding or form content

That gives you the chain, not just the endpoint.

Track each navigation step and record the DOM state at each hop

I prefer a simple rule: every hop gets a record.

If your sandbox gives you a browser-state view, use it to annotate each step. If it does not, you can still build this manually.

Compare visible content, network behavior, and page source side by side

The best habit is to compare three views of the same page:

1. the initial HTML response
2. the live DOM after scripts run
3. the network log

That comparison often exposes the trick immediately. For example, the initial HTML may look like a blank marketing page, the live DOM may contain a login form, and the network log may show a short chain of redirects before the credential capture endpoint appears.

Capture evidence as text: URL chain, timestamps, redirect reasons, and DOM diffs

Do not rely on visual memory. Write down the chain.

A compact note format works well:

10:03:14  https://example.test/lure
          302 -> /gate
10:03:15  https://example.test/gate
          JS redirect after 2.5s -> https://login.example.test/
10:03:18  https://login.example.test/
          DOM mutated: hidden form replaced with visible login prompt

This is better than a screenshot because it is searchable, diffable, and usable in a case report.

What to look for in the DOM and browser data

Sudden changes in forms, login fields, or brand assets

When a page switches identity mid-load, something is usually wrong.

Watch for:

• form fields appearing after load
• changes in button labels
• swapped logos or brand colors
• text that changes after a delay
• input targets that differ from the visible domain

If the form looks legitimate but the submit endpoint does not match the brand, that is the kind of mismatch you want to preserve in evidence.

Hidden elements, opacity tricks, and off-screen overlays

Attackers often hide intent rather than remove it.

Look for:

• display: none
• visibility: hidden
• zero-opacity overlays
• off-screen positioning
• elements with size 1x1 or clipped bounds
• iframes that are present but not obvious

These tactics can hide credential capture fields, click interception layers, or silent tracking frames.

Script-injected content that appears only after load or user interaction

A lot of phishing kits depend on script behavior that static page capture will miss.

Common patterns:

• content inserted after DOMContentLoaded
• elements added only after a timeout
• fields revealed only after a click
• content gated on mouse movement or keyboard events

If the browser-state view shows a mutation log, this is where it earns its keep.

Differences between initial HTML, live DOM, and network responses

A useful way to think about it:

• Initial HTML: what the server first returned
• Live DOM: what the browser actually ended up rendering
• Network responses: what the page fetched after scripts ran

Those three are often not the same. In phishing analysis, that difference is the story.

Reproducible checks you can apply outside ANY.RUN

Use browser devtools to inspect redirects, DOM mutation, and network timing

You do not need a specialized sandbox to get useful evidence. Chrome, Edge, and Firefox all give you enough to reconstruct most redirect chains.

Start with:

• Network tab: preserve log, disable cache
• Elements tab: inspect live DOM after load
• Console: watch for navigation and mutation behavior
• Sources tab: identify inline scripts and injected code paths

If the page looks suspicious, reload with the network log preserved and watch which request actually triggers the next navigation.

Save the initial response, then compare it to the live DOM after scripts run

For a quick comparison, fetch the raw HTML and then inspect what the browser ended up with.

curl -sS -D headers.txt -o initial.html -L 'https://example.test/suspicious'

Then compare the saved response to what your browser shows in Elements. If the live DOM contains nodes that are not in initial.html, you have evidence of client-side mutation.

A simple headless check can help too:

const url = process.argv[2];
if (!url) {
  console.error("usage: node trace.js <url>");
  process.exit(1);
}

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();

page.on("framenavigated", frame => {
  if (frame === page.mainFrame()) {
    console.log("navigated:", page.url());
  }
});

await page.goto(url, { waitUntil: "domcontentloaded" });
await page.waitForTimeout(5000);

console.log("final url:", page.url());
console.log("title:", await page.title());
console.log("body text chars:", await page.locator("body").evaluate(el => el.innerText.length));

await browser.close();

That does not replace a sandbox, but it does surface silent navigation and late DOM changes.

Log the redirect chain with curl, browser console, or a simple headless test

A redirect chain often shows up clearly in plain text:

curl -sS -I -L 'https://example.test/suspicious'

You are looking for repeated Location: headers, status changes, and sudden domain shifts. If the chain is mostly client-side, pair the curl output with browser network logs or a headless script.

Expected pattern:

HTTP/2 302
location: /step-2

HTTP/2 302
location: https://login.example.test/

HTTP/2 200
content-type: text/html

That is enough to tell you the page is not a single static landing page.

What the feature helps with, and where it still falls short

Helps: faster phish triage, better evidence, easier chain reconstruction

This is an evidence-quality improvement first and a UI improvement second.

If the browser-state view is solid, it should help you:

• reconstruct redirect chains faster
• spot DOM-based cloaking
• preserve intermediate states for reports
• distinguish benign landing pages from deceptive ones
• feed more accurate indicators into blocklists and detections

That is real value for SOC work because the chain itself is often the best indicator of intent.

Limits: anti-sandbox behavior, server-side cloaking, geo-based branching, and delayed payloads

This is not magic.

Even a good browser-inspection workflow can still miss cases where the attacker:

• serves different content to sandboxes
• branches on IP geography
• fingerprints timing or device characteristics
• waits long enough to evade short-lived analysis
• uses server-side logic that only returns malicious content to selected visitors

So I would treat the feature as a visibility upgrade, not a complete answer.

Inference versus confirmation: what the report supports and what still needs hands-on validation

Confirmed by the report: ANY.RUN added in-browser data inspection aimed at revealing phishing redirects and DOM changes.

Reasonable inference: this should make analyst reconstruction easier because it exposes browser-state transitions that screenshots hide.

Not confirmed from the provided source: the exact implementation details, detection heuristics, and how well it handles anti-analysis tricks. Those still need hands-on validation with real samples.

Defensive takeaways for SOC and malware analysts

Prioritize the redirect chain as evidence, not just the final URL

When you write up a phishing case, make the chain part of the finding. The first URL, the intermediate hops, and the final destination are all evidence. If you only block the last domain, you may miss the infrastructure that matters.

Feed discovered domains, hashes, and URLs into detection and blocking workflows

Once you have the chain, push it outward:

• add domains to blocklists
• search for related IPs or certificates
• correlate hashes from downloaded payloads
• write detections around redirect patterns and suspicious DOM mutation

The browser evidence is most useful when it turns into controls.

Use DOM-state evidence to improve user training and incident reports

Users understand screenshots, but defenders should report more than screenshots.

Include:

• original lure URL
• redirect chain
• visible text at each hop
• form changes
• timestamps
• final action requested by the page

That makes the incident report much harder to dismiss as “just a weird webpage.”

Conclusion — this is an evidence-quality improvement, not just a nicer UI

The real win is faster reconstruction of attacker behavior during phishing and scam analysis

I like this kind of feature because it shifts the analyst’s job from guessing to reconstructing. The important question is not “what did the page end up looking like?” The important question is “what did the attacker make the browser do, and in what order?”

That is why I think in-browser DOM inspection is a real upgrade for phishing triage. Screenshots are still useful, but the chain is the attack. If a tool helps you preserve that chain, it is doing work that actually matters.

Further reading: source report and vendor documentation

• Source report on ANY.RUN’s in-browser data inspection for phishing redirects and DOM changes
• HTML Standard: meta refresh
• MDN: MutationObserver