The essential distinction
The same signals, used with a different intent.
Websites receive your public network address because they need somewhere to return the response. They use browser and device information to choose compatible layouts, languages, media formats and authentication flows. None of that is inherently malicious.
The privacy and security risk comes from combination and purpose. A phishing kit or traffic distribution system can combine network, browser and interaction signals to identify a desirable target, exclude an analyst or automated scanner, and show different content to different visitors. This is commonly called filtering or cloaking.
| Visible signal | Ordinary purpose | Possible malicious use |
|---|---|---|
| IP, country and ASN | Routing, localization and fraud control | Geofencing, campaign targeting and excluding datacenter or security-company networks |
| Browser and operating system | Compatibility and support | Selecting Windows, macOS or mobile-specific lures and compatible payload paths |
| Language and time zone | Local content and date formatting | Making the lure look native to the visitor's region and working hours |
| Screen and touch support | Responsive design | Separating desktop targets from phones or automated browsing environments |
| Referrer and session markers | Navigation and campaign measurement | Validating the expected lure path, tracking a campaign and suppressing repeat delivery |
| Automation indicators | Abuse and bot prevention | Hiding malicious content from crawlers, sandboxes and security tooling |
From visit to execution
How profiling can become a malware-delivery decision.
The profiling stage usually belongs to the website injection, phishing kit or traffic distribution layer—not to the information stealer itself. A simplified defensive model looks like this:
The request includes network and browser information.
Region, ASN, device, language and automation clues may be combined.
Researchers may see harmless content while matching targets see an overlay.
The page asks the person to run something outside the browser.
Only now can malware inspect protected host and browser data.
Relevant use case
ClickFix: when the visitor completes the infection chain.
ClickFix pages imitate a CAPTCHA, document error, registration problem or browser-update failure. The apparent solution asks the visitor to open the Windows Run dialog, PowerShell or a terminal and execute content supplied by the page. The browser has not silently installed malware; social engineering convinces the person to cross the browser's security boundary manually.
Proofpoint documented campaigns where browser-side JavaScript placed malicious content on the clipboard and the victim was guided through running it. Observed chains delivered loaders, remote-access tooling and information stealers. Other reporting describes compromised sites using filtering before presenting fake CAPTCHA overlays only to selected visitors.
Defensive references: Proofpoint — Clipboard to Compromise ↗ · Proofpoint — TA585 filtering and ClickFix ↗
Before and after compromise
An infostealer sees far more than a webpage.
It is technically important not to merge pre-delivery profiling with post-execution collection. Before execution, a webpage is constrained by the browser sandbox, permission model and same-origin rules. After an infostealer runs as a local process, it may target browser profiles, stored credentials, cookies, session material, cryptocurrency wallets and files according to its capabilities and privileges.
Before malware execution
Browser-visible profile
- Public IP and approximate network location
- Browser, operating system and device class
- Screen, language, time zone and capabilities
- Site-specific cookies and submitted form data
After malware execution
Host-level theft may begin
- Stored credentials and browser history
- Authentication cookies and session tokens
- Wallet data, application secrets and selected files
- System inventory and security-product discovery
CISA lists login credentials, browser history and cookies among data stolen by Vidar Stealer in its joint cybersecurity advisory ↗. Google Threat Intelligence has also documented compromised-site delivery chains distributing multiple infostealer families through resilient web-injection infrastructure ↗.
Practical defense
Break the chain at the human and technical boundaries.
For everyone
- Update browsers through their built-in update screen or the operating system—not an unfamiliar webpage.
- Treat instructions to open Run, PowerShell, Command Prompt or Terminal as a security warning.
- Assume clipboard content supplied by a page is untrusted, even when the visible text looks harmless.
- Use a password manager: a domain mismatch becomes easier to notice and passwords are not reused.
- Remember that a VPN changes network identity but does not erase the rest of the browser profile.
For defenders
- Correlate suspicious web navigation with shell, script-host or living-off-the-land execution by the same user and device.
- Do not require a browser-child relationship: Run-dialog execution can break the obvious process ancestry.
- Inspect command lines, downloaded content, follow-on network traffic and persistence activity as one timeline.
- Use application control and role-appropriate restrictions for scripting engines and unsigned code.
- Train users on the behavior pattern—the fake solution—not only the appearance of one CAPTCHA template.
Method and limitations
What this checker demonstrates—and what it does not.
The live checker demonstrates common connection and browser signals available during an ordinary visit. Browser, screen, language, time-zone and privacy-preference values are calculated in the page. Network information requires a request because every server necessarily receives the address used to connect to it.
The checker does not request exact GPS, camera, microphone or contacts. It also does not currently run canvas, audio, font, WebRTC or DNS-leak fingerprint tests. That matters: the page should not claim to measure signals it does not collect, and the absence of a result here does not prove that another site cannot use a different test.