We sampled 1,531 IPs from Shodan's exposed Ollama index and ran them through ClusterHawk. 919 were honeypots, 60% of the dataset. The remaining 610 real assets clustered into 27 groups, and 13 of those groups belonged to the same operator.

XRUI TECHNOLOGY LIMITED (AS153494, Hong Kong) runs identical nginx/MySQL/Ollama/Express stacks across hundreds of hosts, all tied to wo2u.com and a Chinese sports gambling site. The infrastructure exposes Ollama 0.13.0 on port 11434 across 35+ hosts running Alibaba's qwen3-vl without authentication, MySQL 8.0.36 with 71 CVEs on network-accessible port 3306, and BT Panel management interfaces on port 888. The cluster profiles combine 15+ parameters: TLS fingerprints, HTTP response hashes, organization identifiers, port configurations, domain data, producing detection signatures specific enough to work as high-confidence indicators with minimal false positive risk.

Our analysis is passive: infrastructure fingerprinting from Shodan metadata, not traffic analysis. We can map the attack surface and build detection signatures, but whether these endpoints are already being abused is outside the scope of what passive scanning tells us. The exposure pattern is consistent with documented LLMjacking targeting. Below are five deployable detection rules, a hunting procedure, and the IOCs needed to track this infrastructure going forward.

We started with a Shodan query, "Ollama is running", and pulled everything indexed. ClusterHawk's honeypot detection immediately split the dataset:

Six out of ten IPs were honeypots. When 60% of the observable attack surface is deception infrastructure, you're looking at something every scanner, researcher, and threat actor already knows about. Ollama's zero-auth default has made it a magnet for both exploitation and monitoring.

The 610 that survived filtering are the real infrastructure. Everything below is based on that set.

The clustering result was immediate. Thirteen of twenty-seven clusters share the same hosting provider, software stack, domain, and TLS configuration. We've seen infrastructure convergence before: popular templates produce similar-looking clusters. This wasn't that. This was one operator running a centralized deployment across hundreds of hosts.

The Company

XRUI TECHNOLOGY LIMITED operates AS153494 out of Hong Kong, registered at Hang Fung Industrial Building, Hunghom. They market themselves as a dedicated server provider for "SEO experts" offering "Multiple Class C IPs," designed for operators who need IP diversity across separate /24 subnets, typically for search engine manipulation or content distribution.

Their operational infrastructure sits in the 103.192.40-43.x range, spanning four /24 subnets. Consistent with their pitch: different Class C blocks to create the appearance of distributed, independent infrastructure.

The Domain: wo2u.com

Every well-formed XRUI cluster resolves to wo2u.com: 100% prevalence across all operational groups. The domain serves a Chinese-language sports forum under the title 球坛焦点网 (Sports Forum Focus Network). HTTPS responses carry a consistent favicon hash (-1095953614) across all clusters.

The content matters. Sports forum content in Chinese, hosted on SEO-optimized infrastructure with multiple Class C IPs, managed through BT Panel: this is a Chinese web hosting operation. The Ollama deployment sits alongside this web platform, not instead of it. Someone added AI capabilities to an existing hosting business and never locked the door.

That's the charitable reading. But 35 public-facing hosts running qwen3-vl with Ollama reachable from the internet isn't someone who forgot to close a port. It's a deployment decision repeated across an entire fleet. A hosting provider selling "SEO servers," running a Chinese sports gambling site (a legally grey activity commonly hosted offshore through Hong Kong), with unauthenticated AI inference endpoints open to the internet at scale. This could be negligence. It could also be intentional: inference-for-hire, proxy infrastructure for LLMjacking resale, or AI services offered through channels we can't observe from Shodan metadata. Our passive analysis can't tell the difference. What we can say is that the infrastructure looks indistinguishable from what purpose-built LLMjacking staging would look like.

The Software Stack

The uniformity is the finding. Across 13+ clusters, every operational host runs the same thing:

Same everything, across hundreds of hosts. A single deployment template pushed to every server, which also means a single point of failure. One vulnerability in the shared stack compromises every node.

TLS Fingerprints: The Digital Watermark

The TLS configuration is where attribution becomes detection. The consistency here only comes from automated certificate management:

The JA3S + JARM combination is a strong attribution anchor. Combined with the consistent certificate subject (wo2u.com), issuer (Let's Encrypt R13), and cipher configuration, the resulting detection signature has high specificity. The cluster profiles use 15+ fields, which means they describe the XRUI deployment template and very little else. Any asset matching this TLS configuration alongside the HTTP and domain indicators is XRUI infrastructure with high confidence.

The Let's Encrypt certificates follow a predictable 3-month rotation. Current certificates were issued December 29, 2025 and expire March 29, 2026 (19 days from the date of this analysis). Certificate Transparency logs for wo2u.com will show renewal activity leading up to expiration, a predictable temporal anchor for monitoring.

We ran the 610 filtered assets through ClusterHawk. Twenty-seven clusters fell out, organized into five operational tiers, most belonging to the same entity.

Quality Assessment

Seven Good-rated clusters with excellent internal stability and separation. One achieved the best separation score in the entire dataset. The single Bad-rated cluster is a catch-all for 160 assets that lacked enough distinguishing features for more specific grouping.

The Five Tiers

The XRUI Web+AI Platform tier is the core: 13 clusters sharing the same stack, TLS fingerprints, and domain. What differentiates them internally is service combination: some run BT Panel, others don't; some have Ollama, others are web-only; port profiles vary. ClusterHawk separated what looked like uniform infrastructure into distinct deployment configurations, each with its own operational role and detection signature.

Infrastructure Progression

The clustering reveals what looks like a deployment lifecycle:

Minimal Feature
  → Database Provisioning
    → Full Operational Platform
      → Transitional/Reconfiguring

Hosts in the minimal-feature clusters may be early in the provisioning pipeline, running Ollama (how they entered the dataset) but not yet carrying the full web stack. Database clusters on Amazon infrastructure represent backend provisioning. Fully operational clusters have the complete template deployed. The outlier cluster (142 assets) contains infrastructure in transition: mixed XRUI and non-XRUI hosting, mixed TLS versions. In threat hunting, assets in motion are the ones worth watching.

Ollama binds to 127.0.0.1:11434 by default: localhost only. Getting it on the internet requires setting OLLAMA_HOST=0.0.0.0 and making the port reachable, whether through a public IP, port forward, reverse proxy, or just no firewall rule. In XRUI's case, these hosts sit on public infrastructure with port 11434 answering directly. No authentication, no API key, no TLS. The full API (model enumeration, inference, model download, and filesystem access on older versions) is available to anyone who can reach the port. Across our dataset, 35+ hosts in the XRUI AI clusters run Ollama 0.13.0 with qwen3-vl loaded and accessible.

What's Exposed

The Ollama API on these hosts allows unauthenticated:

• Model enumeration (/api/tags) reveals qwen3-vl and smollm2:135m are loaded
• Arbitrary inference (/api/generate) lets anyone submit prompts and get responses
• Model metadata (/api/show) exposes system prompts, model configuration, parameters
• Model exfiltration (/api/push): CVE-2024-39720 enables model weight theft

The qwen3-vl deployment stands out. Alibaba's multimodal vision-language model processes both text and images. Running it across 35+ hosts suggests either a production AI service or development at meaningful scale. Either way, every instance is a free inference endpoint for anyone who finds it.

Vulnerability Assessment

Credit where it's due: they're running 0.13.0, well past the patch for CVE-2024-37032, the critical path traversal RCE that hit versions before 0.1.34. Probllama isn't a factor. But CVE-2025-15514 (DoS via malformed base64 images, EPSS 0.43) hits every Ollama instance in the dataset.

The real vulnerability isn't any single CVE. It's the architecture. Ollama ships with zero authentication by default. The operator deployed it without adding any. Every AI endpoint in this infrastructure is simultaneously a free inference engine, a model theft target, and a resource abuse vector. No patch fixes that.

The LLMjacking Threat

Sysdig documented this pattern as LLMjacking: attackers find exposed Ollama endpoints, proxy them through OpenAI-compatible reverse proxies, and resell access on Discord and Telegram. Stolen GPU compute has been monetized at over $46,000 per day per compromised fleet. Pillar Security later attributed a specific campaign as Operation Bizarre Bazaar, and SentinelLabs independently documented this infrastructure surface in its Silent Brothers research.

The XRUI infrastructure is a textbook target: unauthenticated Ollama API, production-scale model deployments, co-located web infrastructure for proxy hosting. These endpoints don't need to be "compromised" in any traditional sense: there's nothing to compromise. Anyone who finds them can query the models, enumerate the configuration, and exfiltrate weights. Shodan already indexed them. The API returns HTTP 200. The question isn't whether abuse is possible. It's how much is already happening, and passive analysis can't answer that.

The Ollama exposure doesn't exist in isolation. Every AI endpoint sits alongside a full web application stack, and the co-location creates a multi-stage attack chain worse than any single vulnerability.

The Stack on Every Host

Taking the primary AI inference cluster (35 hosts) as representative:

MySQL: 71 CVEs on Port 3306

MySQL 8.0.36 on port 3306 across the XRUI clusters carries 71 CVEs with an average EPSS of 0.32. The top vulnerabilities (CVE-2026-21964, CVE-2024-21087, CVE-2024-21069) appear on MySQL hosts in the largest web cluster (25 hosts, 71 CVEs, 69 high-risk). CVE-2024-21130 (EPSS 0.39) spans nine clusters: "easily exploitable vulnerability allows high privileged attacker with network access to cause complete DoS of MySQL Server."

None are listed as Known Exploited Vulnerabilities (KEV), suggesting limited real-world exploitation so far. But the MySQL instances are network-accessible on 59+ hosts in the outlier cluster alone, unpatched. Network exposure plus vulnerability density creates a database exfiltration surface that compounds the Ollama risk.

BT Panel: The Management Interface

BT Panel (宝塔面板) is a Chinese server management platform: a web-based control panel for Linux servers. It runs on port 888 across 96-100% of hosts in the web-serving clusters, returning HTTP 403 (access denied but confirming presence). Full administrative access: file management, database access, process control, terminal.

For an attacker who gets in through Ollama or MySQL, BT Panel is the escalation path. For a defender, port 888 with title hash -1030444411 is a reliable indicator of Chinese-managed server infrastructure.

The Attack Chain

1. Discovery      → Shodan/Censys identifies Ollama on port 11434
2. Enumeration    → /api/tags reveals qwen3-vl and smollm2 models
3. Inference      → /api/generate confirms unauthenticated access
4. Model Theft    → /api/push + CVE-2024-39720 exfiltrates model weights
5. Lateral Move   → Express.js (3000) and MySQL (3306) on same host
6. Escalation     → BT Panel (888) or nginx misconfiguration
7. Persistence    → Deploy reverse proxy, cryptominer, or C2 agent

Every step is validated by the clustering data. The services are co-located. The ports are open. The authentication is absent. Whether anyone has walked this chain is unknown. But the path is clear.

ClusterHawk's anomaly detection flagged 31 IPs (5.1% of the clustered dataset) as CRITICAL. No intermediate levels. The scoring measures neighbor consistency across clustering runs: how often an IP gets grouped with the same peers, how stable its neighborhood is, how many distinct clusters it touches. IPs that land in different clusters with different neighbors across runs are the ones behaving differently each time the algorithms evaluate the data.

Top 10 Most Anomalous

The Distribution: Not Where You'd Expect

The anomaly list is dominated by non-XRUI infrastructure: cloud providers, European hosting, Chinese ISPs, South American networks. Only 3 of 31 belong to the XRUI 103.192.x.x range (103.192.40.180, 103.192.40.131, 103.192.43.146). The remaining 28 are scattered across AWS, Hetzner, Alibaba Cloud, Oracle, and various regional providers.

Makes sense. The XRUI infrastructure is uniform (same stack, same template, same fingerprints), so it clusters stably. The anomalous IPs are the ones that don't fit any stable pattern. They entered the dataset through the "Ollama is running" query but share little else with each other or with the XRUI fleet.

Identical Twins: Coherent Sub-Groups in the Noise

Several anomalous IPs share identical detailed features: same neighbor consistency, same stability scores, same unique neighbor ratios, meaning the clustering treats them identically across all runs. These aren't random outliers. They're coherent sub-groups the primary clustering can't stably assign:

AWS cluster (4 IPs: 16.52.157.76, 3.12.148.157, 98.93.255.189, 15.160.190.49): 7 distinct clusters, zero noise frequency, identical neighbor consistency (0.683). Cloud instances with enough shared characteristics to always land together but not enough to form their own stable cluster.

Small-cluster group (6 IPs: 46.4.104.83, 16.171.116.149, 1.13.19.44, 86.20.251.127, 188.245.187.245, 65.108.236.217): 5 distinct clusters, high neighbor consistency (0.835) but very small cluster sizes (mean 24.4). They stick together but get placed in tiny, unstable clusters that shift between runs.

High-ratio group (4 IPs: 131.100.25.162, 192.227.177.10, 47.101.61.248, 121.43.140.23): the most unstable sub-group. Completely different neighbors in some runs, unique neighbor ratio of 4.28 (grouped with 4x more unique IPs than their cluster size across runs), lowest neighbor stability (0.380) of any group. These genuinely don't belong anywhere.

The XRUI Anomalies

The three XRUI IPs, 103.192.40.180 (score 12.06), 103.192.40.131 (score 11.89), and 103.192.43.146 (score 11.89), sit at the lower end of the anomaly spectrum. 103.192.40.180 has low neighbor consistency (0.508) and high unique neighbor ratio (2.29), suggesting it shares some but not all features with the standard template. The other two have high neighbor consistency (0.908) but land in 9 distinct clusters with noise frequency of 0.125, mostly stable but occasionally breaking from the pack. Likely XRUI hosts with partial or non-standard deployments.

We weren't done with the outliers. The 142 IPs in the outlier cluster were too inconsistent for clean classification, but "too inconsistent" is itself a signal. We re-clustered them separately, producing 8 noise clusters and 30 similarity groups. The results reinforced the XRUI story from a completely different angle.

Noise Cluster Distribution

Even among the outliers, 33 of 142 IPs (23%) re-clustered into identifiable XRUI sub-patterns. The remaining 109 are the genuinely diverse infrastructure: the scattered Ollama endpoints we originally expected the entire dataset to be. Hobbyist labs, cloud test instances, miscellaneous deployments that the XRUI dominance overshadowed.

Similarity Groups: Infrastructure Cohesion Under the Noise

The similarity analysis found 30 groups of IPs sharing infrastructural features above a 0.6 threshold. Three stood out:

Similarity Group 5 (34 IPs, score 0.849) is the largest and most cohesive. All 34 in the 103.192.x.x range, sharing HTTP response hashes across ports 8083, 3000, 82, 80, and 443, the full XRUI port profile. Despite being classified as outliers by primary clustering, they share enough infrastructural DNA that similarity analysis groups them back together. XRUI infrastructure sitting between operational tiers: not different enough for clean classification, too similar to be genuinely diverse.

Similarity Group 2 (19 IPs, score 0.746) mixes XRUI addresses with non-XRUI infrastructure including IPs associated with Bergische Universitaet Wuppertal. Cross-organizational similarity like this is unusual, possibly the same web framework or template producing similar response hashes across unrelated operators.

Similarity Group 9 (16 IPs, score 0.675) is XRUI infrastructure sharing Ollama port (11434) hashes alongside the standard web stack. The AI-enabled outlier hosts that primary clustering couldn't assign to a single XRUI AI cluster.

The True Anomalies

Three IPs were classified as true outliers, outliers within the outliers: 103.192.40.147, 103.192.41.26 (both anomaly score 1.635), and 117.72.118.118 (score 0.0001). The first two are XRUI addresses running the full stack including qwen3-vl, but with configuration differences significant enough to resist classification at every level. Most likely undergoing active reconfiguration or serving a unique operational role.

The third, 117.72.118.118, is the interesting one. It shares XRUI features across multiple similarity groups but operates from a different ASN. A potential indicator that the operator's footprint extends beyond the core 103.192.x.x range.

The operator doesn't keep everything on XRUI infrastructure. Four clusters, grouped by MySQL characteristics rather than Ollama or web features, sit on Amazon Data Services across multiple regions.

Every IP was discovered via the "Ollama is running" query: these Amazon assets had Ollama at the time of indexing. But clustering used MySQL on port 3306 as the dominant identifying characteristic, with none of the web stack present on XRUI clusters. The separation looks deliberate: web-facing infrastructure on XRUI's Hong Kong ASN, database backends on Amazon's global network. The operator understands that co-locating everything on one provider creates a single point of disruption.

It also creates a detection challenge. The XRUI clusters have highly specific profiles: compound fingerprints built from 15+ parameters. The Amazon database clusters are the opposite: their profiles reduce to something like port:3306, matching millions of MySQL instances globally (the largest cluster maps to ~3.15 million Shodan results). The databases hide in the noise while the web infrastructure stands out. Correlating the two is how you map the full network.

Six clusters contain a combined 258 assets that the algorithm grouped together based on what they don't have: the rich feature sets found in operational XRUI clusters. They all came in through the Ollama query but lacked the specific combination of nginx, MySQL, Express, BT Panel, TLS certificates, and domain indicators that define the operational tiers.

The largest holds 160 assets, the single largest cluster and the only one rated Bad. ClusterHawk generates no Shodan queries for these clusters because there are no compound feature combinations to describe. The clustering signal comes from feature absence, not feature presence.

These likely represent:

• Minimal-service Ollama deployments: hosts running Ollama without the full web stack
• SEO IP pool: addresses provisioned for backlink diversity, consistent with XRUI's "Multiple Class C IPs" offering, with Ollama as a secondary service
• Recently provisioned infrastructure that isn't yet fully configured
• Hosts behind stricter firewalls, where Shodan captured the Ollama banner but couldn't enumerate additional services

The SEO interpretation aligns with XRUI's business model. Providers selling "Multiple Class C IPs for SEO" provision large address blocks for clients who need IP diversity for search engine manipulation. Some may run only basic services: their value is existing across different /24 subnets, not what they host.

We formulated hypotheses before running the analysis. Here's what the data said:

Managed Platform Leak was the clear winner, and the surprise. We expected it as one pattern among many. Instead it dominates. One hosting provider's deployment template, pushed uniformly across hundreds of assets, creating a fingerprint so consistent it became its own detection signature.

One operator, one stack, one domain. The detection surface is narrow and well-defined.

Rule 1: XRUI TLS Fingerprint (HIGH Confidence)

title: XRUI Infrastructure TLS Fingerprint Detection
description: Detect TLS connections matching XRUI operational infrastructure
detection:
  selection:
    tls.ja3s: "574866101f64002c6421cc329e4d5458"
    tls.jarm: "3fd3fd0003fd3fd21c42d42d000000bdfc58c9a46434368cf60aa440385763"
  condition: all of selection
fields:
  - destination.ip
  - tls.certificate.subject
note: >
  High specificity — this TLS combination is characteristic of the XRUI deployment template. Covers all operational XRUI
  clusters. Detection confidence: 85%. Any hit is highly likely XRUI infrastructure.

Rule 2: XRUI HTTP Fingerprint (HIGH Confidence)

title: XRUI Web Platform HTTP Detection
description: Detect HTTP responses matching XRUI web infrastructure
detection:
  selection:
    http.headers_hash: 1245094173
    http.favicon.hash: -1095953614
    http.robots_hash: 1330548294
    destination.port: [80, 443, 82]
  condition: selection
note: >
  High specificity — compound HTTP fingerprint characteristic of XRUI web platform. Complements Rule 1 for environments
  without TLS inspection.

Rule 3: Exposed Ollama API (HIGH Confidence)

title: Ollama AI API Exposure Detection
description: Detect connections to exposed Ollama inference endpoints
detection:
  selection:
    destination.port: 11434
    http.status: 200
  filter_local:
    destination.ip: ["127.0.0.1", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
  condition: selection and not filter_local
note: >
  Broader than XRUI-specific — covers any exposed Ollama endpoint. Combine with Rule 1 for XRUI attribution.

Rule 4: BT Panel Management Interface (MEDIUM Confidence)

title: BT Panel Management Interface Detection
description: Detect BT Panel management interfaces
detection:
  selection:
    destination.port: 888
    http.status: 403
    http.title_hash: -1030444411
  condition: selection
note: >
  Covers XRUI web-serving clusters. Indicates Chinese-managed server infrastructure.

Rule 5: wo2u.com Domain Tracking (HIGH Confidence)

title: wo2u.com Domain Activity Detection
description: Monitor DNS and certificate usage for wo2u.com
detection:
  selection_dns:
    dns.question.name: ["wo2u.com", "www.wo2u.com"]
  selection_cert:
    tls.certificate.subject.cn: "wo2u.com"
    tls.certificate.issuer.cn: "R13"
  condition: selection_dns or selection_cert
note: >
  Primary domain across all operational clusters. Watch Certificate Transparency logs for renewal ~March 20-29.

Hunting Procedure

XRUI Infrastructure Hunt:

1. BASELINE
   TLS: JA3S 574866101f64002c6421cc329e4d5458
        JARM 3fd3fd0003fd3fd21c42d42d000000bdfc58c9a46434368cf60aa440385763
   HTTP: headers_hash 1245094173, favicon_hash -1095953614, robots_hash 1330548294
   Domain: wo2u.com | Certificate issuer: R13 (Let's Encrypt)
   Ports: 80, 82, 443, 888, 3000, 3306, 8083, 11434

2. DETECTION DEPLOYMENT
   Deploy Rules 1-5 above
   Alert on any combination of 3+ matching fingerprints
   Monitor Ollama API (11434) connections from external networks

3. EXPANSION TRACKING
   Search for new assets in 103.192.40-43.x range
   Monitor Let's Encrypt CT logs for wo2u.com renewals
   Track AS153494 for new IP allocations

4. CROSS-CLUSTER CORRELATION
   MySQL hash 880948174 links AI, web, and outlier clusters
   Ollama model configs link all AI inference clusters
   BT Panel (port 888) links all web-serving clusters

For All Roles

CRITICAL:

• Deploy TLS fingerprint detection (JA3S + JARM) for real-time monitoring: covers 80%+ of operational XRUI assets with high confidence
• Block or alert on connections to port 11434 (Ollama API) from untrusted networks

HIGH:

• Monitor wo2u.com domain resolution and certificate issuance via CT logs
• Track favicon hash -1095953614 in HTTP responses across all web clusters

For Threat Hunters

• Start with the TLS fingerprint (Rule 1), a high-confidence XRUI indicator
• Hunt for Ollama API endpoints serving qwen3-vl and smollm2:135m models
• Investigate the 31 CRITICAL anomalous IPs, outliers that don't fit stable patterns
• Cross-reference MySQL hash 880948174 across network telemetry
• Watch for new infrastructure in the 103.192.40-43.x range

For SOC Analysts

• Deploy Rules 1-5 for automated alerting
• Monitor HTTP 403 responses on port 888 with title hash -1030444411, a BT Panel indicator
• Alert on TLSv1.3 connections with certificate subject wo2u.com and issuer R13

For Intelligence Analysts

• Track AS153494 infrastructure expansion and new prefix announcements
• Correlate qwen3-vl model deployment patterns with emerging LLMjacking campaigns
• Monitor wo2u.com registration changes and new subdomain creation
• Certificate rotation expected ~March 20-29: watch for infrastructure refresh patterns

The input was a list of 1,531 IPs. Everything after that was automatic.

ClusterHawk took the raw IP list and, without human tuning, feature selection, or threshold adjustment, produced the entire analytical foundation behind this article: honeypot filtering, ensemble clustering, quality assessment, anomaly detection, noise re-analysis, similarity grouping, compound detection signature generation. The 27 clusters, the five operational tiers, the 31 anomalous IPs, the coherent sub-groups in the noise, the dual-provider infrastructure separation: all of it came out of the pipeline.

A Shodan query for org:"XRUI TECHNOLOGY LIMITED" returns the hosts. What it doesn't tell you is that those hosts operate in 27 distinct deployment configurations, that 142 outliers still contain 23% identifiable XRUI sub-patterns, that 4 database clusters on Amazon infrastructure are operationally linked to the web fleet, or that 31 non-XRUI IPs show coherent clustering instability suggesting separate operators. ClusterHawk separated what looked like uniform infrastructure into distinct operational tiers, each with its own detection signature, automatically.

What the pipeline delivered:

• Honeypot filtering: 919 deception assets identified and excluded with 100% confidence, before clustering
• 27 cluster profiles, each with compound infrastructural fingerprints (up to 15+ parameters) for matching new infrastructure
• Quality assessment: per-cluster stability and separation scoring, flagging the single Bad-rated catch-all
• Noise re-clustering: 142 outlier IPs re-analyzed into 8 sub-clusters and 30 similarity groups
• Anomaly scoring: 31 critical IPs flagged for neighbor instability across clustering runs
• Detection signatures: compound Shodan queries generated per cluster, ready for deployment

The analysis ran at two independent tiers, INTERMEDIATE and ADVANCED, and both converged on the same findings: same XRUI dominance, same 31 anomaly count, same infrastructure patterns. Different configurations, same conclusions. That convergence is the validation.

ClusterHawk is Chawkr's infrastructure clustering platform. Learn more at clusterhawk.chawkr.com.

Fingerprints

Top Anomalous IPs (Highest Priority)

These IPs exhibited extreme clustering instability, assets that don't fit any stable infrastructure pattern:

46.4.104.83
16.52.157.76
51.16.40.30
131.100.25.162
3.17.173.171
180.102.134.42
18.169.162.191
177.71.167.32
98.93.255.189
3.12.148.157

Note: The anomaly list is dominated by non-XRUI infrastructure: AWS, Hetzner, Alibaba Cloud, regional providers. These are Ollama-hosting IPs that don't fit the dominant patterns. Several form coherent sub-groups with identical clustering behavior, suggesting shared deployment templates from other operators. The XRUI infrastructure itself is highly stable: TLS and HTTP fingerprints remain the durable detection anchors.

175,000 exposed Ollama endpoints make a large attack surface. What makes this subset actionable is that it's identifiable. One Hong Kong hosting provider, a uniform software stack, a Chinese sports forum, and an unauthenticated AI inference layer across all of it, profiled into compound detection signatures built from 15+ parameters. The 60% honeypot rate tells us this surface is already under active observation. The detection signatures here give defenders a way to do something about it.

XRUI TECHNOLOGY LIMITED isn't an APT. It's not a botnet. It's a commercial web hosting operation that bolted AI inference onto its existing platform without securing it, creating the largest identifiable cluster of exposed Ollama infrastructure we've found under a single operator. The attack chain (unauthenticated Ollama API to MySQL exploitation to BT Panel escalation) is documented above. Five detection rules, TLS fingerprints, HTTP hashes, and domain indicators are ready for deployment.

Even the outliers held up. When we re-clustered the 142 IPs that primary analysis couldn't cleanly classify, 23% grouped back into XRUI sub-patterns. Similarity Group 5 (34 IPs, score 0.849) showed the same port profile, same HTTP hashes, same wo2u.com domain. Infrastructure too noisy for primary clustering was still too XRUI to be anything else. The profiles are durable.

One JA3S. One JARM. One domain. One operator. The certificates expire March 29. Deploy the rules now, and track the renewal.

• Sysdig: LLMjacking: Stolen Cloud Credentials Used in New AI Attack (2024) https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/

• Pillar Security: Operation Bizarre Bazaar: First Attributed LLMjacking Campaign with Commercial Marketplace Monetization (2024) https://www.pillar.security/blog/operation-bizarre-bazaar-first-attributed-llmjacking-campaign-with-commercial-marketplace-monetization

• SentinelLabs & Censys: Silent Brothers: Ollama Hosts Form Anonymous AI Network Beyond Platform Guardrails (January 2026) https://www.sentinelone.com/labs/silent-brothers-ollama-hosts-form-anonymous-ai-network-beyond-platform-guardrails/

• Censys: Ollama Drama: Investigating the Prevalence of Ollama Open Instances (September 2025) https://censys.com/blog/ollama-drama-investigating-the-prevalence-of-ollama-open-instances-with-censys/

• NVD: CVE-2025-15514: Ollama Null Pointer Dereference (2025) https://nvd.nist.gov/vuln/detail/CVE-2025-15514

• NVD: CVE-2024-37032: Ollama Path Traversal (Probllama) (2024) https://nvd.nist.gov/vuln/detail/CVE-2024-37032

• Ollama GitHub: Security Advisory: Model Registry Path Traversal (2024) https://github.com/ollama/ollama/security

• MITRE ATT&CK: Resource Development: Acquire Infrastructure https://attack.mitre.org/techniques/T1583/