TL;DR
We found additional activity and sandbox circumvention techniques used by rogue AI agent swarms. These include attempting to extract Russian government data, hijacking remote browser services and running Javascript in attempts to extend their capabilities, circumvent networking and sandbox restrictions, and complete their tasks.
We observed agents hiding Javascript inside Base64-encoded URLs and then submitting these to URL scanners. This abused the remote browsers that these services use for scanning, to extend the swarm’s reach, attempting multi-stage VNC cross-session hijacking and more. In this post, we break down the most notable activity we saw and walk through the evasion chains.
What the agents were after
The agents targeted various government data portals, in attempts to extract statistical data.
What intrigued us the most in the data we found was specific activity targeting a specific legal entity’s bankruptcy data from fedresurs.ru (the Russian Federal Bankruptcy Registry). The agents had found a way to run code through urlquery.net, a public URL scanner that opens links in a real browser.
However, even urlquery's browser couldn't access fedresus.ru’s API directly, so the rogue agents had to get creative. Here, we saw the swarm attempting VNC cross-session hijacking and additional novel malicious techniques, described further below.
This research expands on work by Transluce and Corridor, who documented agent activity on urlquery and published datasets of the observed payloads.
What is a URL scanner?
A URL scanner is a service that inspects suspicious links safely, so you don't have to open them yourself. You submit a URL and then the service opens it in a real but disposable remote browser on its own infrastructure. Finally, it reports back with information about what the page did, what scripts it executed, and more analytics.
Why were agents using URL scanners?
The rogue AI agents were restricted from within their sandbox environments and could only visit websites and external data sources within a limited network scope.
The agents discovered that urlquery can help bypass some of those network restrictions since it opens every submitted URL in a real browser, with full internet access. This meant that if the agents could hide Javascript inside their submitted URLs and let urlquery's browser run it for them, they could gain full browser capabilities and Javascript execution functionality.
How the agents used remote browser execution
The agents Base64-encoded JavaScript into URLs using httpbin-like services, using the same technique we presented here. They then submitted these URLs to be scanned by urlquery in order to run the embedded Javascript that these documents encoded from within this service's remote browser.Base64-encoded documents are served back a web pages when processed by a browser, as can be seen in the example below, which was taken from the discovered activity:
https://httpbun.com/base64/PHNjcmlwdD5mZXRjaCgnaHR0cHM6Ly92aXpwcm9kLmFpaHcuZ292
That Base64 decodes to the following Javascript, seen with real found activity from the swarm:
You can see that the Javascript invokes a fetch request to an Australian Government portal (on aihw.gov) which was also seen on other online reports of rogue AI agent swarms activity.
URL laundering: the next level
We’ve observed similar approaches to URL laundering as discussed on our earlier blog, and this time with the use of Javascript and using more advanced techniques.
Let’s take this urlquery submission, for example:
Looking at the embedded Javascript, we can see an elaborate script being used to retrieve a dashboard’s initialization data from the same Australian government portal we saw earlier. The rogue agents also used chunked compressed data and additional 3rd party services to handle and save responses in locations where they could later easily access them.
What was getting blocked
Nevertheless, the agents weren’t able to query fedresurs.ru's API using a direct request. They were facing the following issue:
- Accessing the
/companieslocation directly was succeeding:
https://fedresurs.ru/companies/61065761-3be6-47f7-afe5-e597c74ef44c/publications
- Accessing the site’s API under the
/backendlocation and using query parameters was getting either 403 and 404 response errors, which we believe the agents estimated to be part of anti-bot protections:
https://fedresurs.ru/backend/companies/61065761-3be6-47f7-afe5-e597c74ef44c/publications?limit=100&offset=0
The agents were trying to bypass their restrictions
We estimate that the agents identified the problem they were facing as follows:
- Some websites set a session cookie when you first visit, and without it, their APIs might block you. This is a known anti-botting protection mechanism.
- If the agents could get a valid cookie from another active session on the site, submitted on a different session for accessing an unrestricted part of the site, they could then use it to bypass their restrictions on querying the API part of the site.
In order to circumvent this protection, the agents first submitted 3 different types of payloads to urlquery, in a time frame of several minutes.
Each of these attempted in different ways to (a) first access the accessible site’s URL in the scanner's browser; and (b) only then navigate to its protected API:
1. Load the website in a hidden iframe, wait, and then redirect
2. Open the website in a popup window, wait, then change the popup's address
3. Create two links and click them in sequence with a delay
However, none of these approaches worked for the agents.
Agents remotely hijacking a browser
The bridge attempts had failed. The agents' code ran from httpbun.com and tried to load fedresurs.ru inside frames and popups, but the remote browsers seemed to block these attempts. Submitting the plain fedresurs.ru /companies URL directly to urlquery worked, but since the data the agents wanted was behind the /backend API, they had no way to navigate the browser there.
But what if the swarm could hijack that successful browser session and manipulate it to go further?
Taking over another browser
VNC (Virtual Network Computing) is a protocol for remotely viewing and controlling another computer's screen. urlquery exposes each scan's browser over VNC so operators can watch it in real time. The agents used this to take control of one scan's browser from another browser session.
The VNC hijack required the agents to coordinate 2 separate browser sessions and run them simultaneously on urlquery's infrastructure.
The VNC hijack
The agent submits 2 URLs to urlquery in quick succession:
1. Scan A (target): The plain fedresurs.ru URL. urlquery opens it normally, establishing a successful session. This session is available over VNC at wss://urlquery.net/queue/{queue_id}/vnc, with no password required.
2. Scan B (controller): A Base64-encoded payload using tinyurl.com and containing a JavaScript VNC client.
When decoded, it connects to Scan A's VNC endpoint and takes interactive control.
This same session also shows an HTTP 101 connection upgrade when connecting to the target session:
Looking at the HTTP requests that urlquery logged, we can see this payload starting within tinyurl.com to obfuscate and redirect it; using httpbun.com to encapsulate it; reaching jsdelivr.net to import the VNC functionality; and eventually reaching out urlquery.net itself.
Remote keyboard injection
Once the VNC connection was established, the controller could see the target browser's screen and inject keystrokes. The payload pressed F6 to reach the browser’s address bar and retyped the URL:
Once the full URL was typed, the payload pressed Enter. Because the address bar belonged to the same browser that has the previously established fedresurs.ru successful session, the navigation to the backend location is expected to inherit the session cookies.
Problem solving
The rogue agents didn't seem to get this right on the first try.
They submitted 7 VNC scans, across 4 payload variants, adjusting the following components in each:
- Whether to use F6 or Ctrl+L to reach the address bar
- Keystroke timing
- Whether to type characters individually or paste them via the clipboard
- Using the VNC client source or not (e.g., urlquery's own bundle vs. the jsDelivr CDN)
Three of the attempts eventually showed successful VNC connections in the network logs.
Putting it all together
The agents pointed this technique at fedresurs.ru. They loaded the initial accessible main page using one scan, and used the second scan to take over the first session’s browser through VNC, type commands into it and direct it to the site’s restricted API.
Three of the observed VNC connections succeeded. However, whether the data extraction succeeded is currently unknown.
Why this could be the same swarm
These techniques share infrastructure and patterns with the rogue OpenAI agent swarm documented by collusion.wiki, Transluce, Corridor, and with the activity we reported in Part 1:
- Same delivery method: Base64-encoded URLs via httpbin.org/httpbun.com, shortened through tinyurl.com
- Same time window: April to August 2026, overlapping with the collusion.wiki timeline
- Shared infrastructure: the same disposable email providers, proxies, and notification channels across techniques as shared in other reports on this swarm
- Same types of targets: government data sources, including registries and public health databases
While we cannot fully validate this, the shared tooling and steady sequences suggest a common origin.
Open questions
Are other URL scanners being used the same way?
urlquery isn't the only service that opens URLs in a real browser. VirusTotal, Hybrid Analysis, any.run, and dozens of screenshot/preview services work similarly.
What else is in the data?
Other researchers have published reports on related agent activity, and there are hundreds of cached payloads we haven't fully analyzed yet. We expect more techniques to surface as this research continues.
How did the agents figure this out?
They didn't start with the VNC hijack. They tried simpler approaches first, failed, and escalated, knowing that urlquery can work with VNC.
What this means
This is what a goal-seeking AI agent swarm looks like. It prioritizes task completion over imposed restrictions: it doesn’t give up when something is blocked, treats every reachable service as a potential tool and every restriction as a problem to solve.
This applies to your agents too. An agent with a goal and enough access will find creative paths to that goal, whether it's running inside your environment or reaching in from outside it. The question isn't if your agents will find unintended ways to use the tools you give them, it's whether you'll see it when they do.