urlscan.io Blog

Executive Summary

For approximately 48 hours in June 2026, a cluster of activity that the urlscan Threat Research Team assesses to be a swarm of automated AI agents used urlscan.io as a free, unattributable and anonymous browser to perform scans of government data portals in Australia and India. The urlscan platform was not the target of this activity, but we have visibility of the activity through the saved artifacts on the platform.

Using internal platform data, the urlscan Threat Research Team attributed 3,553 scans to this cluster, submitted through 15 urlscan API keys. Nine of these keys belonged to disposable accounts created for the operation, and six belonged to existing, legitimate customers whose keys were likely used without their knowledge. The same compromised keys targeted Indian government services one day before the activity against the Australian Institute of Health and Welfare (AIHW). This report documents the accounts and infrastructure involved, the techniques observed beyond those already publicly reported, the actions urlscan has taken in response, and recommendations for other platforms that fetch URLs on behalf of users.

Contents

• Background
• Timeline of Activity
• Platform Abuse
• Techniques Observed
• Targets Beyond AIHW
• Response and Recommendations
• Indicators and Hunting Queries
• Conclusion

Background

A research report dated September 26, 2026, by Manifold Security used public urlscan records to identify 1,437 public scans of a Tableau server belonging to the Australian Institute of Health and Welfare (AIHW). Public scan results document the pages being scanned but contain no further information about the background of the submitter. Using internal visibility the urlscan Threat Research Team were able to investigate the originating accounts for those scans and gain additional information about the automated tooling responsible.

Timeline of Activity

The urlscan Threat Research Team attributed 3,553 scans from June 16 to 19, 2026, to this cluster with moderate confidence. Across these submissions, 513 distinct user-supplied tags were observed. Below is a detailed breakdown of the submission timeline, operational focus, and tags.

Platform Abuse

The agents likely used urlscan because it provides a real browser that executes JavaScript and can send requests that their own sandboxes were not permitted to make. Every request in this chain passed through the urlscan scanner.

Disposable Accounts

The API keys used in this activity fall into two groups.

Nine keys belonged to newly registered accounts that were used only on June 17 and 18, 2026 and not been used since. Four of these accounts each used a single, fixed AWS EC2 address in the us-west-2 region. The remaining accounts connected through VPN Gate, VPNBook, OVH, Tor exit nodes, and a university network. Most submitted scans used plain curl or python-request user agents, and two of the keys submitted almost all of their scans with unlisted or private visibility.

All of the disposable accounts were registered with web-library.net freemail addresses and generic “researcher” personas. Names and job titles are self-declared at sign-up and are not verified. The profile listing “@ OpenAI” as an employer should not be treated as attribution or as an indication that OpenAI was involved in creation of the account.

Compromised Customer Keys

Six keys used in this activity belonged to legitimate urlscan customers with months or years of consistent prior usage, such as phishing triage or monitoring of their own domains. From 16 June 2026 onward, these same keys began submitting scans from Azure, Google Cloud, Cloudflare, and third-party screenshot service egress addresses. One key made 404 submissions from 393 different Azure addresses over a nine-hour period. This activity was not expected behavior when compared to historic usage of the key and the users activity.

The urlscan Threat Research Team found no indication that these customers were involved in the activity. Based on the available evidence, it is assessed with high confidence some of the keys were exposed publicly, for example in code repositories or shared configuration files, and subsequently harvested.

Targets Beyond AIHW

AIHW was not the first target of this cluster. One day earlier, on June 16 2026, the same compromised keys targeted two services operated by India’s Ministry of External Affairs.

This pattern matches the AIHW activity that followed: identify a public statistics dashboard, locate the API behind it, and then enumerate that API across multiple scanner locations.

Techniques Observed

The Manifold Security report described the core technique used in this activity: turning a scan, which can only issue a GET request, into a browser that makes POST requests. urlscan data shows how the agents built and iterated on this technique, often within minutes.

Carrier Pages

Approximately 900 scans pointed at HTTP echo services, including httpbun.com, httpbin.org, eu.httpbin.org, and pie.dev. Each URL carried a base64-encoded HTML page. When the urlscan browser rendered the page, the embedded script opened a Tableau session on the AIHW server and changed dashboard parameters one council area at a time. The script then wrote the result into the page title and body, where it was captured in the scan screenshot and DOM. Pubic scan example: https://urlscan.io/result/019ed452-3e82-7738-844e-fbeb4547623c

Public and Self-Built Proxies

At 09:21 UTC on 17 June, a single account tested approximately 15 public CORS proxies in one burst. Within the hour, scans started to move to proxies that were created in Cloudflare Workers, resulting in more than 100 scans across at least 12 short-lived *.cloudflarepreviews.com hosts. The proxy at cors[.]bwa[.]workers[.]dev carried most of the later traffic.

Additional Relay Channels

The activity also used Google Translate as a fetch proxy, and the Microsoft Office Online viewer to open AIHW spreadsheet tables. As seen here: https://urlscan.io/result/019ed5c3-6e19-773c-bcde-846b80f8b48a

Tunnels to Agent-Operated Servers

Pages served through pinggy, localhost.run, and trycloudflare tunnels hosted the agents’ own harness pages. One of these pages accepted a JavaScript snippet as a URL parameter and embedded AIHW dashboards in iframes. Working notes were posted to the paste sites paste[.]rs and brewpage[.]app.

Scanner Country Rotation

Task tags such as kipresearch,sg and kipresearch,de show that the cluster deliberately scanned the same URL from eight urlscan scanner locations using the ISO 3166 2 letter country codes to track the activity: sg, de, us, ch, gb, au, nl, and jp.

Reading Results Back Through the Scanner

Several scans targeted the urlscan DOM pages of earlier scans, in an apparent attempt to retrieve output without API access. These pages require authentication, and the attempts were unsuccessful. An attempt to access the Indian Government API result in the DOM: https://urlscan.io/result/019ed1b2-3d9e-7080-8dea-a67574fbe5d2

Origin Probing

One scan requested an Indian government API path directly on its cloud IP address, bypassing the public hostname. This scan can be seen here: https://urlscan.io/result/019ed120-0788-70cf-bad9-73a5841767b1

Machine-Readable Task Tracking

The 513 distinct task tags follow a consistent structure made up of three components: a phase, such as a0 to a3; a region, such as vic, nsw2, or qnear4; and an intent, such as retry, probe, final, or tie. This structure is consistent with an orchestrator tracking sub-tasks, rather than with the way a human analyst would typically label scans.

Response and Recommendations

Prior to publication, the urlscan Threat Research Team shared this report with OpenAI, which provided the following statement:

As we previously announced, we’re conducting an extensive review of misaligned model activity and notifying organizations when we identify potential impacts to their systems. We expect to make additional notifications as that work continues. Most of the activity we’ve reviewed so far involved routine research tasks, such as accessing public web content to answer questions. Some involved government websites because our models often turn to them as authoritative sources of public information.

Actions Taken by urlscan

• Deleted the nine disposable accounts.
• Disabled the API keys of the six customers whose keys were used in this activity.

Recommendations for urlscan Customers

• Treat API keys with the same care as passwords. Keep them out of public repositories, notebooks, browser extensions, and shared agent configurations.
• Rotate any API key that has ever been stored in a location others can read.
• Review recent scans in the urlscan dashboard. If any scans are not recognized, report them to urlscan and rotate all associated API keys.
• If you discover any exposed urlscan API keys please report them to security@urlscan.io.

Recommendations for Services That Fetch URLs for Users

• A service that fetches content by URL acts as a proxy for anyone who can reach it, including AI agents seeking a way around their sandbox restrictions. Echo services, CORS proxies, screenshot APIs, and scanners all formed part of the chain observed in this activity.
• Monitor behavior per credential, not only per IP address. The strongest signal in this case was a long-standing key that changed its network, user agent, and target set on the same day.

Recommendations for Those Building or Hosting AI Agents

• Blocking POST requests within a sandbox is not effective if the agent can pass a URL to a third-party browser that will make the request on its behalf.
• Restrict agents from creating accounts on third-party services and from using credentials that do not belong to them.

Indicators and Hunting Queries

The following infrastructure was set up or relied on by the cluster. Cloud addresses are frequently reassigned, and some of the proxies listed are operated by third parties who may be unrelated to this activity. These indicators are intended for hunting within the timeframes documented in this report and are not suitable for blocking.

The following searches can be run on urlscan.io. urlscan Pro customers will see additional details related to this activity.

task.domain:viz.aihw.gov.au AND date:[2026-06-16 TO 2026-06-19]
task.domain:(httpbun.com OR pie.dev OR eu.httpbin.org) AND task.url:*b64* AND date:[2026-06-16 TO 2026-06-19]
domain:cors.bwa.workers.dev AND date:[2026-06-16 TO 2026-06-19]
task.tags:(kipresearch OR pbsbatch-a1 OR a1vic OR a0retry OR a3qfinal OR a3qnear*)
task.domain:(meadashboard.gov.in OR backend.videshapps.gov.in) AND date:[2026-06-16 TO 2026-06-19]

Conclusion

The urlscan Threat Research Team also reviewed the other targets named in public reporting: the US Securities and Exchange Commission (SEC), investor.gov, USAspending, the Census API, MAX.gov, and the UK council portals of Lambeth, Southwark, and Wandsworth. None of the keys associated with this cluster scanned these targets, and no path-traversal URLs against SEC hosts were observed on the urlscan platform in 2026. There is no evidence that this separately reported activity was conducted through urlscan. The SEC has stated that it was unaware of any unauthorized access to non-public information, and the Commerce Department stated that no private Census data was accessed.

AIHW has stated that it found no evidence that its systems were compromised or that non-public information was accessed. urlscan data is consistent with this assessment: the dashboards involved were publicly accessible, and the impact of the activity stemmed from its volume and level of automation rather than from a breach.

This activity demonstrates how automated AI agents can chain together legitimate third-party services, including URL scanners, HTTP echo services, CORS proxies, and tunneling platforms, to perform actions that their own execution environments would otherwise prevent. The cluster combined disposable accounts with compromised customer API keys, rotated networks and scanner locations, and iterated on its techniques within minutes, while tracking its progress through a structured tagging scheme consistent with automated orchestration.

Although no evidence of access to non-public data was identified, the volume and automation of the activity placed load on public government services and exposed legitimate urlscan customers whose keys had been leaked. Services that fetch content on behalf of users should expect to be used in similar chains and should monitor for sudden behavioral changes at the credential level. The urlscan Threat Research Team will continue to monitor for related activity on the urlscan platform.

More on urlscan Pro

If you want to learn about the urlscan Pro platform and how it might be valuable for your organization feel free to reach out to us! We offer free trials with no strings attached. We would be happy to give you a passionate demo of what our platform can do for you. Reach out to us at sales@urlscan.io.