URL analysis

What URL analysis is

Malwagon URL analysis takes one http or https link and opens it in a real browser inside a virtual machine built for that single run. It returns a screenshot of each page in the redirect chain, the body of every response the browser received, any file the page served, the decrypted HTTP transactions, a packet capture and a screen recording.

What happens when you submit a link?

The machine resumes from a live memory snapshot with a browser already on screen, the link is fetched over a real network path, and the disk the browsing happened on is destroyed at the end of the run; nothing is cleaned up and handed on. No part of the link is resolved, fetched or rendered on the analysis host, including the site's own favicon.

target: One http or https URL per submission, up to 2048 characters. The host may be a name, an internationalised name in punycode, an IPv4 literal or a bracketed IPv6 literal.
guest: A Linux image carrying a browser and no desktop, with no image selector on this module. A small driver in the guest starts the browser and writes down what it saw. Nothing else runs there.
run length: 60 seconds of browsing, fixed. Finishing early is honoured by the guest loop; there is no duration field and no extend control.
egress: Unconditional and paid-plan only. A plan without internet egress is refused at the form, because the run it would be given browses nothing.
capture: Packets are recorded at the hypervisor tap and the screen through the hypervisor, both from outside the guest. A page that closes the browser or blanks the tab does not remove either recording.
kept: Page captures, every response body, any file the page served, the packet capture, the TLS key material and the screen recording.

The submission surface is deliberately narrow. Most of what a file detonation asks you to choose does not apply to a page, so it is not offered: no work path, no start arguments, no pre-script, no archive password, no dump selection, no execution mode.

The submission surface, and what each field will not take.
Field	Accepted	Refused
Scheme	http, https. A bare host is read as https.	Everything else. A browsing guest has one job.
Length	2048 chars	Longer, at the form and at the API alike.
Host	DNS name, punycode or IDN name, IPv4 literal, bracketed IPv6 literal.	Nothing at this layer. A host that does not resolve is recorded as a navigation error; the submission itself is valid.
Characters	Anything a URI may carry, percent-encoded where it must be.	Carriage return, line feed, NUL, double quote and backslash, refused before the run is built. The value becomes part of the guest's run definition, where every one of those characters carries structural meaning.
Browser identity	One of eight fixed identities, applied to both browsers in the run.	Nothing. An identity the platform no longer offers falls back to the default, so a form left open across a release still submits.
Layers	Static, dynamic and AI, at least one. Static and dynamic start on.	All three off. Dynamic off gives a static-only run: URL structure and reputation, no machine.
Submitter	A paid plan whose entitlement includes internet egress.	Anonymous submissions, which this module is not offered for, and free and Community accounts. A paid plan without egress is refused at submit, before a credit is debited.
Count	One URL per console submission.	A list. The REST bulk route queues several, and each one becomes its own independent run.

Refusing is the safe answer

A URL run with no egress produces a report with no navigations, no responses and no capture, and at a glance that report reads like a clean verdict. The module declines the submission at the form, so no such report is ever produced. The same rule holds one layer down: if the egress lock cannot be installed on the bridge, the run aborts; it never proceeds without it.

One frame per navigation

A shortened link that lands on a lure that redirects into a credential page is four different pages, and a single final screenshot tells you about one of them. The run captures a full-page screenshot at each page change, deduplicated by content hash, so a chain reads as a sequence and a page that renders identically twice does not produce two frames. Pop-ups and tabs the page opens itself are captured on the same rule.

Four hops, three frames and a payload. Each navigation is stored as its own numbered screenshot with the URL, the page title, the reason the frame was taken and its offset into the run; the last hop serves a file and draws no page, so the run says so explicitly and does not present an empty tab as a failed capture. The band underneath is recorded whether or not anything is drawn.

The visual chain can be shorter than the network chain, and the report says which one you are reading. A redirect that resolves too quickly to be captured on its own leaves no frame behind, and that hop is recovered from the response table and the packet capture.

What a capture set looks like

A set reads as a timeline, not as a folder of pictures. Each frame is filed with the URL it was taken on, the page title, the reason it was taken and its offset into the run, so the set can be read in order and each frame can be tied back to a row in the response table.

The set a single run hands back. The reason field is what makes it readable: it separates the first load from a navigation, from a window the page opened for itself, and from the state the run ended in. Frames are stored to a budget, and the report states when that budget was reached and does not trail off without a word.

What one run returns

What one URL run produces, by artifact class.
Artifact	What it is	How it comes back
Page capture	A full-page screenshot taken at each page change, with the URL, the title, the reason and the timestamp. Deduplicated by content hash.	An image per distinct rendered state, bounded per run.
Page resource	The body of every response the browser received, with status, content type and byte size. The stylesheet and the kit's own script are the same class of evidence as the payload.	A raw attachment, downloaded and never rendered inline. Each body also becomes a sample of its own, addressed by hash, so it can be pivoted on later.
Served payload	A file the page delivered to the browser, with the URL it came from, the filename the page suggested, the size and the SHA-256. The transfer is waited out so a truncated file is not mistaken for a complete one.	A password-protected archive, filed under its own artifact type so it stays clear of every stylesheet the page fetched.
Screen recording	The guest display for the whole session, taken through the hypervisor, including anything the analyst did by hand in the live browser.	One recording per run, on the report.
Packet capture	The frames the guest sent and received, taken at the tap interface outside the guest.	Written to host storage for the scan, alongside the key material that decrypts it.
Dialogs and console	JavaScript dialogs the page raised, by type and message, recorded and then dismissed so they do not hold the run open. Browser console messages alongside them.	Two bounded lists on the report.
Favicon	The site's icon, fetched from inside the guest through the page's own request context, so it travels over the same network, origin and cookies the browser used.	Accepted only if its own bytes match a known raster type, then re-encoded from the bytes the host validated, and shown on every list and search result for that scan.

A file the page serves

A file the page serves is not treated as an attachment to a screenshot. It goes through the same second-stage static chain a submitted file would: typing, PE parsing, entropy, packer identification, code-signing and trust state, YARA matching with family attribution, malware-configuration extraction, AV signature scanning and hash-only reputation against open abuse feeds. Anything that chain independently names is evidence about the URL and moves the verdict on its own. A payload that was not analysed is listed with the reason it was not.

What a capture record holds

A capture recordillustration

capture   03
url       hxxps://sso.example/verify
title     Account verification
reason    navigation
offset    11.4s
artifact  page-03.png

Written for this page; no scan produced it. Every stored capture carries these fields, so a frame in the report can be tied back to a row in the response table and to a point in the screen recording.

Why open the same link under more than one identity?

Because a cloaking page that serves a decoy to a visitor it does not recognise serves something different to each one. The form offers a set of fixed browser identities, and each carries its own engine string, platform claim, viewport shape and the touch, mobile and pixel-ratio flags that travel with it. Submitting the same link twice under two identities is how you collect both pages.

Device shape counts for as much as the string. A mobile-only redirect reads touch support, the mobile flag and the device pixel ratio, so the phone identities assert all three and do not simply swap a header and hope.

One limit decides how much the rest is worth: an identity changes what the browser reports about itself, and a single rendering engine executes every run. A kit that fingerprints engine behaviour and ignores the string it was handed sees the same engine under each identity, and the choice buys nothing against it.

What an identity changes

The eight identities, by what the page can actually observe.
Identity	Engine string family	Platform claimed	Viewport	Touch, mobile flag, high DPR
Default desktop	Family A	Windows desktop	desktop wide	None
Desktop, second vendor token	Family A, with a second vendor token appended	Windows desktop	desktop wide	None
Alternate engine, Windows	Family B	Windows desktop	desktop wide	None
Alternate engine, Linux	Family B	Linux desktop	desktop wide	None
Third-family desktop	Family C	Desktop, neither Windows nor Linux	desktop large	None
Primary-family desktop	Family A	Desktop, neither Windows nor Linux	desktop large	None
Phone, primary family	Family A	Phone	phone portrait	asserted
Phone, third family	Family C	Phone	phone portrait	asserted

Three engine-string families across three desktop platforms and two phone platforms. The console names each identity in full on the form. The literal header strings and their pinned version numbers are not published: they fingerprint this sandbox, and they would be out of date within a release.

Whichever identity you pick is applied to both browsers in the run, so the automated capture and the screen you are driving are one visitor to the site; a single scan never ends up holding two differently fingerprinted pages. Naming an identity also costs you the fastest start path, on purpose: a run that names one declines the pre-warmed browser and launches its own, because a browser that started before the run existed is already carrying somebody else's identity.

Reading inside TLS without a proxy

Nearly everything worth reading on a hostile page happens inside HTTPS. Malwagon recovers it without terminating the connection: no interception proxy stands in the path, and no extra certificate is installed in the guest. The browser exports its own session keys, the capture is taken at the hypervisor tap, and the two are joined on the host after the guest is powered off. The site is handed an ordinary browser and an ordinary certificate chain; the analyst still reads the credential POST.

No interception proxy and no certificate installed in the guest. Two artifacts come out of the run and are joined afterwards on the host, which is why the connection the site sees looks like a browser and not like an inspection point. The join happens once the guest is powered off, so no step of it is exposed to the page while the page is still running.

A reconstructed requestillustration

POST /verify HTTP/2
:authority     sso.example
:scheme        https
content-type   application/x-www-form-urlencoded
user-agent     the identity this run was given

user=j.smith%40example.com&pass=[redacted, 14 bytes]

secret scan    1 match, redacted
paired with    HTTP/2 302, location: hxxps://sso.example/dl/update.msi

Written for this page. HTTP/2 carries no request-in field and the wire never states the pairing, so it is reconstructed from the stream. Credential and secret patterns are scanned across request and response content alike, and what they match is reported redacted.

Network evidence from the run's own capture

Network evidence produced from a URL run's own capture.
Layer	What it yields
Tap capture	The packets the guest sent and received, recorded at the hypervisor, outside the browser, so the record does not depend on what the page left alone.
TLS handshakes	Destination, SNI, negotiated version, ALPN, and JA3 and JA4 client fingerprints.
Decrypted HTTP	HTTP/1.1 and HTTP/2 transactions: method, URI, version, status, full header sets on both sides, decoded and bounded bodies, request and response paired.
Secret scan	Credential and secret patterns across decrypted request and response content, reported redacted.
DNS	Queries and the answers returned. Encrypted DNS is switched off in the guest on purpose, so every name lookup stays readable on the wire.
Cleartext protocols	Application protocols the page or its payload spoke without TLS.
IDS	Signature alerts over the capture from an open ruleset, served by a warm daemon so a scan pays only for reading the capture; the rules are compiled already.
Derived intelligence	Domain-generation-algorithm scoring, beacon periodicity and jitter, and fast-flux detection, each computed only over indicators that survived baseline filtering.
Fingerprint reputation	Surviving JA3 and JA4 values matched against local threat data, and treated as corroboration only: a fingerprint names a TLS library, and benign software on the same stack shares it.
Baseline filtering	A count of exactly what operating-system and browser vendor infrastructure was removed across DNS, TLS, HTTP and the intelligence layer.

That last row is the one worth dwelling on. An empty network view has two very different causes: the guest opened nothing, or everything it opened was known-benign infrastructure that was filtered out. A report that cannot count what it removed cannot tell you which, and that is exactly the gap traffic fronted behind a large content-delivery network hides in.

Where this lands

All of it is computed on every URL scan, stored with the run, weighed into the score and carried into the structured threat-intelligence bundle and the plain indicator exports. The URL report page does not draw it as a network tab of its own: this evidence reaches the reader through the verdict rationale, the stored analysis document and the export routes.

The guest that does the browsing

The browsing happens on a full virtual machine under a hypervisor, on hardware the operator runs. Each run gets a throwaway copy-on-write overlay over a read-only golden image, restored from a live memory snapshot with a browser already up and parked on a locally served waiting page. The submitted link is on screen about a second after the guest receives its job, with no boot and no browser start to sit through. That waiting page suppresses its own referrer, so the site is handed no address from inside the sandbox, and no debugger is attached to the tab that renders hostile content, which leaves no automation port on it for a payload to drive.

When the run ends the overlay is discarded and the next run resumes the same snapshot, so a guest is not cleaned up and passed on with the last page's residue in it. The machine starts quickly because it is new, not because something scrubbed it.

What is recorded from outside the guest

The packet capture is taken at the hypervisor tap and the screen recording through the hypervisor, so neither one is produced by software running inside the machine the page has. A sample that kills the browser or unhooks the driver still appears in the capture and on the recording. The driver in the guest supplies the page-level detail those two cannot carry, the response bodies, page titles, dialog text and the served file, and it is a second source on top of them, so a run that loses it comes back with a network record and a recording anyway.

Two browsers in one run

One headless pass builds the report while a separate full-screen browser is drawn on the guest's own display for you to watch and drive. Input to the live screen stays gated until the guest confirms the page is actually on it, and your session is screen-recorded into the same report, so the record covers what a person did as well as the automated pass.

What is closed on that machine

Containment on that display is by absence, not by a toolbar you could unhide. Downloads are left working on purpose, because a drive-by download is the thing being analysed; what is closed is the interface around it.

nothing spare: The image is built for one job and carries nothing it does not need to do it: a browser, the driver that starts it, and the system underneath the two. There is no interactive surface on that machine for a page to reach for, and nothing there for it to hand a file to.
closed by policy: Developer tools, file selection dialogs, printing, local-file and browser-internal schemes and external protocol hand-off, all closed by managed policy baked into the image, so every window the browser opens inherits them; a switch set per window would be missed.
no escape keys: Console-switching and server-kill key chords are disabled, accounts are locked, and the reboot and magic-key routes are severed per run in the throwaway overlay.
silenced browser: Speculative prefetch, search suggestion, encrypted DNS and hyperlink auditing are all switched off. The last two on purpose: name lookups stay visible on the wire, and a ping the page itself fires is attributed to the page.
egress lock: On the one bridge that reaches the internet, guest-to-operator-LAN forwarding is dropped, abuse-associated ports are dropped, and new connections are rate-capped per source while established transfers run untouched.
untrusted results: Results are read out of the powered-off guest offline. Symlinks and non-regular entries in the guest-written tree are refused, guest-chosen ownership and permissions are discarded, and no file type the guest or the site asserted is believed.

The browser's own traffic

Suppressing what the browser says on its own account is part of the evidence, not tidiness. Left alone, a browser reaches its vendor's infrastructure on every start, and each of those lookups would arrive in the network table and the indicator list as though the page had asked for it. The policy is baked into the image, which is what makes it hold for any window that opens, including one the page opened for itself.

Did the run actually reach the page?

The report answers that before it says anything about the link, because a page that did nothing and a run that never got there produce documents that look identical, and they lead an analyst to opposite actions: this link is safe against nobody has looked at this link yet. The browsing guest reports its own progress in the shape the Windows detonation agent uses, so a single classifier grades every platform: whether the driver started, whether the browser launched, whether navigation was issued, against which URL, at what offset into the run, plus a bounded list of the guest's own notes.

How each outcome is stated

How each outcome is stated, and what it declines to say.
Outcome	What the report asserts	What it refuses to assert
The guest never reported in	The run did not reach the page, named with its failure class.	Anything at all about the link.
Guest up, browser never launched	The platform failed, not the page.	Anything at all about the link.
Navigation issued, site returned a browser error page	The platform worked and the site did not answer usefully.	That the page did anything. An error page counts as the sandbox working and explicitly does not count as behaviour.
Page reached, nothing further happened	The page was reached and did nothing during this window.	That the link is safe. A quiet run is one observation, not a clearance.
The URL served a file and drew no page	The URL is flagged as serving a file, and the report points at the payload and its static analysis.	That screen capture failed. There is no page and no recording worth showing, and the report says which.
The run worked	Navigation issued, the URL it was issued against, the offset in seconds, the captures, the bodies and anything served.	Telemetry it does not have. The source histogram is left empty, never filled with invented buckets, and no process identifier is minted for a navigation.

What this module does not do

It is not a crawler: One URL, one page, plus any window the page opens itself. No link following, no depth, no site walk, no sitemap, no authentication, no form filling and no scripted interaction. Anything past the first page happens because you did it by hand over VNC.
One engine under every identity: The identity list changes headers and device shape. A kit that fingerprints engine behaviour and ignores the string it was handed is unaffected by the choice.
The visual chain can be short: A redirect that resolves too quickly to be captured on its own leaves no frame behind. The hop survives in the response table and in the packet capture, and the report is read from there.
No runtime phishing-kit detection: The only phishing signal computed is a structural heuristic over the URL string, calculated without contacting the site: scheme and authority shape, homograph and punycode hosts, subdomain depth, abused top-level domains, brand impersonation outside the registered domain, and credential-harvest and kit path markers. There is no credential-field detection, no MFA-relay detection and no kit-family identification at runtime. What a phishing page is doing is what you read in the captures, the bodies and the decrypted requests.
No script emulation on page content: Page JavaScript is executed by the browser and captured. It is neither deobfuscated nor emulated here; that layer belongs to the command module.
No host telemetry, and none is faked: Nothing runs in that guest except the browser, so there is no process tree, no file or registry events, no memory forensics, no kernel trace and no Sigma matching. There is also no blocked-by-policy table: the firewall drop counters are bracketed on the Windows detonation path only, so a URL run does not report what egress policy refused.
Fixed run length: 60 seconds, with no duration field and no extend control. A longer look is one resubmission away, and finishing early is honoured by the guest loop.
Everything captured is bounded: Page captures, response bodies, served payloads, the favicon, the decrypted body excerpt and the console log all run to a budget. Past it a response is still listed at its real size with no stored copy, and an oversized served file is reported as served with no copy kept, so the report states where it stopped. The ceilings themselves are not published: a page that knows the budget can flood past it and then serve the payload.
The report page is narrower than the data: The network, intelligence and indicator sections a file report draws are not drawn on a URL report, and the export buttons offered on the page are the AI narrative report in PDF and DOCX only. The data is produced and stored either way, and the export routes return it.
The AI layer sees little of the browse: Its dynamic summary is assembled from the behavioural fields a Windows detonation produces, and a browsing guest produces none of them, so the model works from the URL's structural findings, the indicator list and the run-integrity facts. The narrative is thinner here than on a file detonation, which is worth knowing before you lean on it.
Weak evidence stays weak: A TLS fingerprint names a library that many clients share, so fingerprint reputation is corroboration and carries no verdict by itself. Address spread alone does not separate a rotating C2 from a large content-delivery network, and the fast-flux finding says as much on its own face.
Geolocation and ASN mapping are optional: They require a third-party data licence and are feature-flagged off without one.
The live view is best effort: If the guest's display server does not come up, the run still analyses the page headlessly and the console says so; no black screen is left up to read as a dead machine. The headless pass and the recording carry the run in that case.
No YARA or Sigma rule from a URL run: There is no binary and no host telemetry to build one from. Network signatures are generated from the indicators the run actually observed, and none are emitted for a run whose verdict came out clean, so a shipped rule does not contradict the report that produced it.

Running one

URL analysis is a paid module because it needs a controllable machine that is allowed onto the internet, and Malwagon does not hand that machine to an account that costs nothing to open. Submit a link from the console, or through the API and MCP surfaces with the module set to url and the link as the target. What comes back over the API is the derived-indicator view: verdict and score, the URL's structural findings, the indicator list, the reputation summary and the run-integrity facts. The page captures, the response bodies and the served payloads are console artifacts and stay here.

The platform page covers the detonation environment the other modules share, API and MCP covers the automation surfaces, security covers isolation and what leaves the platform, and pricing says which plans carry internet egress.

Neighbouring modules

The rail lists seven modules, and this is the one whose sample is a link. A payload this module captures is already a file, and the file module is where it goes next, on a Windows or Linux image you pick. Command analysis takes a script or a command line as the sample; document analysis opens a weaponised document in the application it targets; the kernel driver and BYOVD module reads a Windows driver's IOCTL surface without running it; package analysis installs a package by name and watches the install itself; and a OneShot run puts one sample on several images at once.