We received 50 validated IPs linked to a suspected Russian state-sponsored APT. We profiled them through ClusterHawk and extracted a common fingerprint: RDP on port 3389, self-signed windows-{City} certificates, two JARM hashes, hosted almost entirely on RouterHosting LLC, the entity behind Cloudzy, a provider that Halcyon Research flagged as a Command-and-Control Provider (C2P) used by over 17 nation-state groups.

Pivoting on that profile against internet scanning data surfaced approximately 1,900 matching assets. We ran the full set back through ClusterHawk and the results were striking: 40 distinct clusters, 95% rated "Good" or better, zero Bad clusters. A fleet that looked uniform on the surface turned out to have clear internal structure: two OS tiers, geographic provisioning templates, provider diversification, and six clusters with highly specific fingerprints that produced no overlapping results elsewhere at the time of analysis.

At the time of analysis, every major reputation provider returned clean scores for these IPs. Traditional IOC feeds had not flagged them. The infrastructure profile caught what reputation feeds missed.

The expanded profile also creates an attribution problem. The seed data says Russian APT. The infrastructure says US-based C2P provider, RDP-only, no domains, no tooling artifacts: nothing that matches the documented tradecraft of the groups typically associated with that attribution. Whether this is a single operator, an Initial Access Broker operation, or multi-actor convergence on a cheap hosting provider remains an open question. We lay out the evidence and let the reader draw their own conclusions.

We designate this infrastructure tracking effort OVERCAST, a name chosen deliberately. The name reflects the challenge of this investigation: infrastructure that was hiding in plain sight, clean scores across every reputation feed, a gray sky with no distinguishable features, until you knew what pattern to look for.

50 IP addresses were shared with us: validated indicators tied to a suspected Russian state-sponsored APT. Not speculative. Not reputation-only. These were confirmed active infrastructure from collaborative threat intelligence.

The Initial Profile

We fed the 50 IPs into ClusterHawk. At 50 assets you're not doing real clustering: there isn't enough variance. But even basic profiling on this prefiltered, validated set surfaced a surprisingly clean fingerprint:

• Port 3389 exclusively: RDP as the sole exposed service
• Self-signed certificates where both issuer CN and subject CN follow a windows-{City} naming pattern
• RouterHosting LLC as the dominant host (AS14956)
• Two JARM fingerprints: one TLSv1.2, one TLSv1.3
• Two screenshot hashes: Windows RDP login screens (one per OS generation: Server 2012 R2 and Server 2025 present different default login pages)

Clean enough to pivot on.

From 50 to 1,900

We queried internet scanning data with the full profile (certificate pattern, JARM fingerprints, JA3S hashes, screenshot hashes) and got back approximately 1,900 matches. The initial 50 weren't a cluster. They were a sample from a much larger fleet.

That changed everything. Fifty IPs give you a profile. Nineteen hundred give you a dataset, enough to cluster by certificate configs, TLS negotiation stacks, RDP encryption methods, screenshot states, and geographic provisioning. ClusterHawk generated profiles for each cluster, which we used to map the fleet's internal structure, cross-cluster correlations, and deployment patterns.

Our operating assumption from that point: these IPs either are or will become malicious. The profile match is too specific and too consistent with the validated set to be coincidence. We flag everything that matches and monitor proactively rather than waiting for individual confirmation.

Here's what makes this interesting: at the time of analysis, every major reputation provider scored these IPs as clean: not malicious, not suspicious, clean. Traditional IOC feeds hadn't caught up. The profile-based approach identified 1,900 assets that reputation services were waving through, which is exactly the gap that profile-based infrastructure tracking is designed to fill.

And the fleet doesn't sit still. Over the course of our monitoring, we observed approximately 800 IPs rotating out every two weeks, replaced by new ones matching the same profile. The total fleet size stayed consistent at around 1,800, but the individual addresses churned steadily. With limited resources, we could only snapshot the fleet biweekly; more frequent tracking would likely reveal smaller, more continuous rotations. This churn rate means that any static IP blocklist goes stale within days. The fingerprint (certificate pattern, JARM, provider) is the only durable detection anchor.

Every asset in this fleet uses a self-signed RDP certificate where both the issuer CN and subject CN follow the same pattern: windows-{City}. It's the single most distinctive feature of OVERCAST infrastructure.

The NetBIOS Constraint

The 15-character NetBIOS name limit forces some creative encoding. windows- takes 8 characters, leaving exactly 7 for the location identifier. The rules are consistent:

This isn't arbitrary. The suffixes on shorter city names encode VPS tier information: 2g likely indicates 2GB RAM, 4g indicates 4GB, 8g indicates 8GB, 12 indicates 12GB, while 1H and 4H suggest high-performance tiers with 1 and 4 cores respectively. A subset of hostnames uses a regional prefix pattern (US-, UK-, DE-, NL-, SG-) before the city abbreviation, consuming additional characters but providing geographic context. The operator is using Cloudzy's RDP VPS provisioning templates directly, with the hostname automatically generated from the selected datacenter location and plan tier.

Known Hostnames (Selected)

We've observed 25+ distinct hostnames in the wild. The full list is longer, but the pattern is consistent, and that's the point. IPs rotate on a roughly biweekly cycle. Certificates get reissued. But the hostname stays because it's baked into the VPS provisioning template. For threat hunters, certificate CN monitoring is the most durable detection anchor for this infrastructure, one of the few that survives the churn.

Fingerprint Summary

Note: The JARM and JA3S fingerprints are generic Windows RDP signatures: they identify the server-side TLS implementation, not the actor. Their value comes from combining them with the certificate pattern and hosting provider, not from the hashes alone.

Hosting Provider Distribution

The provider distribution tells its own story:

~85% of assets on a single ASN. That's not just a hosting preference. It's a procurement pipeline. RouterHosting is the entity behind Cloudzy (AS14956), which Halcyon Research flagged as a C2P with 40-60% of its traffic supporting malicious activity. The cloudzy.com domain shows up at near-100% prevalence across the fleet.

The remaining ~15% breaks into two very different stories.

FranTech, Hyonix, anyNode (~12%): the Cloudzy reseller chain. Halcyon documented that Cloudzy rents infrastructure through at least 12 ISPs, FranTech Solutions among them. And our data confirms it: FranTech appears in five clusters, Hyonix in two, anyNode in one, and every single one of those clusters still shows cloudzy.com at near-100% domain prevalence. Same naming templates, same certificate patterns, same JARM fingerprints. These aren't independent providers: they're Cloudzy resold under different ASNs. The operator is buying the same product through alternate checkout lanes, and the most likely reason is takedown resilience. If RouterHosting gets abuse-actioned, capacity on FranTech and Hyonix stays up. That's a procurement strategy, not coincidence.

Vultr, Cox, Aqueous Cloud, Bytesize (~3%): the outliers. These are mainstream providers with no documented Cloudzy relationship, and they don't fit the same pattern. One cluster is particularly telling: a mix of Vultr and Cloudzy assets sitting side by side, which shouldn't happen if the operator is exclusively procuring through the Cloudzy ecosystem. A few hypotheses: these could be profile contamination, a different operator running coincidentally similar RDP infrastructure that matched our pivot query. They could be test nodes the OVERCAST operator spun up on cheaper providers. Or they could be assets that simply don't belong in this dataset at all. Cox Communications in particular is a residential ISP, which is unusual for bulk VPS procurement. We flag these as low-confidence OVERCAST attribution and recommend treating them as anomalies until further correlation confirms or rules them out.

Operating System Split

Two OS generations, cleanly split. About 75% of the fleet runs Windows Server 2012 R2, end of extended support since October 2023. No security patches, which means every post-EOL RDP vulnerability stays permanently exploitable. These are cheap VPS instances, adequate for RDP relay, and the operator clearly doesn't care about patching them.

The other ~25% runs a build reporting as 10.0.26100. In a VPS context, this is Windows Server 2025, though it's worth noting the build number is shared with Windows 11 24H2 (same NT kernel). The TLSv1.3-only configuration on these assets refuses TLSv1.2 fallback, which is a noticeably more hardened posture. This tier represents the newest provisioning wave. The operator is modernizing, but keeping the cheap legacy fleet running alongside it.

Geographic Distribution

The US concentration (73%) mirrors Cloudzy's datacenter footprint. The European and Asian nodes (London, Amsterdam, Frankfurt, Singapore) give the operator relay points in different jurisdictions.

Dubai stands out. Only 10 assets carry windows-Dubai-2 naming, and as we'll see in the clustering analysis, Dubai falls into one of six clusters whose full query fingerprints returned no overlapping results at the time of analysis.

We ran the full 1,900-asset dataset through ClusterHawk. Result: 40 distinct clusters plus 1 outlier.

We expected this to be difficult. Look at the cluster descriptions: every single one is fundamentally "RDP on port 3389 with a windows-{City} certificate." The core fingerprint is identical across all 40 clusters. What differentiates them is the broader detail: TLS version, cipher suite, specific certificate CN, hosting organization, HTTP response hash, screenshot state, certificate timestamps, geographic location. The clusters reflect deployment batches and provisioning templates rather than functionally different infrastructure. These aren't 40 different things: they're 40 variations of the same thing, and that granularity is what makes detection precise.

Infrastructure Cluster Groups

The 40 clusters organize into five operational categories:

The Two-Tier Architecture

The clustering consistently separates the fleet into two primary groups, matching the OS/TLS split observed in the raw infrastructure data:

Tier 1: TLSv1.2 Legacy Fleet (~29 clusters, ~1,425 assets)

• JARM: 26d26d16d26d26d22c26d26d26d26dfd9c9d14e4f4f67f94f0359f8b28f532
• JA3S: 649d6810e8392f63dc311eecb6b7098b
• OS: Windows Server 2012 R2 (end-of-life)
• RDP encryption: 128-bit Client Compatible mode with 40-bit and 56-bit fallback
• Security protocols: Hybrid (TLS + CredSSP), Hybrid (TLS + CredSSP EX), Standard RDP Security, TLS 1.0/1.1/1.2

This is the workhorse fleet, provisioned in bulk with identical configurations. End-of-life OS, legacy encryption, four-protocol RDP stack, all the same across every asset. Certificate issuance dates span August 2025 through February 2026, so provisioning has been continuous for at least six months.

The biggest single cluster is the Dallas node (236 assets, all windows-Dallas0), 12.4% of the entire fleet. All RouterHosting, all identical TLS. Certificate expirations spread across 2026, which means the refresh cycle is ongoing. This cluster is also where most of the anomalous IPs land (20+ assets with extreme membership instability), making it the most likely location for active infrastructure transitions.

Other major nodes: Utah (146 assets), Las Vegas (141), London (130), and a secondary Utah node on FranTech (101). An interesting wrinkle: four clusters all use windows-Utah-2g naming but land in separate groups because their HTTP hashes and hosting organizations differ. Same geographic template, compartmentalized across providers.

Tier 2: TLSv1.3 Modern Fleet (~11 clusters, ~475 assets)

• JARM: 14d14d00014d14d08c000000000000217f0fec773ec97f0b3fdd2de2993c31
• JA3S: 6c2811f7ba8e88604ea41a2bf9fa5ad7
• OS: Windows Server 2025 (build 10.0.26100)
• TLS: TLSv1.3 with TLS_AES_256_GCM_SHA384

The modern fleet runs TLSv1.3 exclusively: the 14d14d... JARM means these servers refuse TLSv1.2 fallback entirely. More hardened than the legacy tier by design.

The standout is a mixed-geography cluster (72 assets): Las Vegas (50%), Frankfurt (19%), Singapore (18%), the newest OS in the fleet. When the full cluster fingerprint is queried against internet scanning data, no additional results come back. The query may be too specific to surface overlap, but it also means the signature is precise enough for high-confidence detection. More on this below.

One detail worth noting across all TLSv1.3 clusters: every single asset, all 475+ of them, returns the same screenshot hash (-1311134363), which captures an "Administrator Password" login prompt. The TLSv1.2 fleet returns a different hash (29478602) showing the older "Windows Server 2012R2" login screen. The two hashes map directly to the two OS generations, not language variants, but different default login pages from different Windows versions. The uniformity within each tier means automated deployment with no post-provisioning customization.

Cross-Cluster Correlations

The Utah-2g correlation (Rank 1) is the strongest in the dataset: four clusters sharing an identical geographic template but differentiated by HTTP hash and hosting organization. Two sit on RouterHosting, one on FranTech Solutions, one on Hyonix LLC. From a detection perspective, a single certificate CN query covers all four, while provider-specific queries enable cluster-level attribution.

The Dallas correlation (Rank 2) reveals two clusters as sub-populations of the same base Dallas template, differentiated by cloudzy.com domain prevalence, suggesting different provisioning batches or operational segments within the Dallas fleet.

Six clusters produced query fingerprints specific enough that, at the time of analysis, they returned no additional results when run against global internet scanning data. This could mean the signatures are genuinely unique to OVERCAST, or it could mean the queries were narrow enough to exclude similar infrastructure that doesn't match every parameter. Either way, the specificity makes them useful for high-confidence detection.

The TLSv1.3 Multi-Continent Cluster: Most Specific Signature

Seventy-two assets, the newest OS in the fleet, spread across Las Vegas (50%), Frankfurt (19%), and Singapore (18%). The multi-continent distribution suggests this isn't a test batch. It's operational infrastructure deployed globally with intent.

The detection signature combines JARM 14d14d..., JA3S 6c2811f7..., HTTP hash 68505244, and screenshot hash -1311134363. Matching all four narrows results to this cluster specifically, which makes it the most actionable signature in the dataset for targeted detection.

The Dubai Geographic Anomaly

Ten assets, all carrying the hostname windows-Dubai-2 with 100% cloudzy.com domain association. The Dubai naming pattern appears nowhere else in the 1,900-asset dataset. As a TLSv1.2 cluster with windows-Dubai-2 naming, it represents the only Middle Eastern presence in the fleet.

These assets may represent:

• A specialized operational node for Middle Eastern operations
• A geographically strategic relay point for regional routing
• A test or staging environment with a purpose-built deployment template
• An expansion of operations in the area

The UK-London Regional Variant

Fifty assets using the regional prefix variant windows-UK-Lond rather than the standard windows-London0 seen in the much larger London cluster (130 assets). Both serve the same geographic location, but the naming divergence and distinct query fingerprint suggest a separate provisioning batch or operational segment, potentially a different customer or campaign within the same C2P ecosystem.

What This Means

254 assets across six clusters, spanning both TLS tiers and three hosting providers. Their query fingerprints are specific enough that no external overlap was found at the time of analysis: 13.4% of the fleet behind signatures narrow enough for high-confidence detection.

These IPs all scored clean on reputation at the time of analysis. No blocklist caught them. No threat feed flagged them. The infrastructure fingerprints are what make detection possible here, and the specificity of these six cluster signatures makes them a practical starting point for detection rules.

You can't understand OVERCAST without understanding where it lives. Cloudzy, formerly RouterHosting and rebranded in 2021, is not a conventional hosting company.

The Provider Profile

• ASN: AS14956
• Domain: cloudzy.com
• Registration: US-registered (Sheridan, WY, via Cloud Peak Law Group as registered agent)
• Alleged operation: Tehran, Iran via abrNOC (Halcyon Research assessment)
• Services: VPS, RDP VPS, dedicated servers
• Payment: Accepts cryptocurrency with minimal identity verification
• Data centers: 15+ globally (US, UK, NL, DE, SG, and others)

Halcyon Research's 2023 investigation found that Cloudzy's infrastructure supported operations by at least 17 nation-state APT groups. When Halcyon researchers purchased services, they described the process as "cheap, easy, and anonymous", requiring only an email address and a cryptocurrency payment. No identity verification, no business justification, no questions asked.

Documented Threat Actor Usage

Halcyon estimated that 40-60% of Cloudzy's total hosted servers support potentially malicious activity. The company's connection to abrNOC, an Iranian cloud hosting operation, raises additional concerns about jurisdictional enforcement and takedown cooperation.

The 50 seed IPs came with a clear label: Russian state-sponsored APT. But when we expanded to 1,900 assets, the question became: does that attribution apply to the whole fleet, or just to the 50 IPs that happened to be in it?

What We Actually Know

The expanded profile is RDP-only, hosted ~85% through a US-registered C2P with Iranian operational ties, no domains, no tooling artifacts, no payloads observed. That doesn't contradict the seed attribution, it just doesn't confirm it either. It also doesn't narrow it.

A 2021 joint advisory from CISA, NSA, and FBI (AA21-116A) documented Russia's SVR (APT29) routinely using commercial VPS providers, specifically in the same country as their targets, to avoid geographic detection heuristics. Microsoft's 2024 disclosure on the Midnight Blizzard corporate breach showed the same group using residential proxy networks and commercial VPS infrastructure to blend with legitimate traffic. And in November 2024, SentinelOne documented North Korea's BlueNoroff group using "virtual server hosting services such as Quickpacket, Routerhosting, Hostwinds" for C2 infrastructure in their Hidden Risk campaign targeting cryptocurrency firms, the same RouterHosting that hosts ~85% of OVERCAST.

The point is straightforward: state actors from multiple nations use the same commercial hosting providers, often the same ones, and infrastructure choices alone cannot distinguish between them.

Hypotheses

The more productive question is what this infrastructure is for. These are not mutually exclusive:

1. Initial Access Broker (IAB) infrastructure. The scale (1,900 assets), uniform configuration, RDP-only exposure, and clean reputation scores fit the IAB operational model. Group-IB's Hi-Tech Crime Trends 2023/2024 report documented 3,055 instances of network access for sale in 2024 alone (a 15% increase over 2023) with RDP remaining among the top access types offered. Before law enforcement seized the xDedic marketplace in January 2019, it listed over 700,000 compromised RDP servers across 150,000+ in the United States alone, generating an estimated $68 million in fraud. The successor ecosystem (Russian Market, Genesis Market before its April 2023 seizure) operates at similar scale. An access broker needs clean IPs: burned infrastructure has no resale value. OVERCAST's steady churn of ~800 IPs every two weeks with zero reputation degradation is consistent with a managed commercial operation where infrastructure hygiene is the product.

2. Operational segmentation. State actors routinely compartmentalize infrastructure by mission type. Mandiant has documented APT29 maintaining separate infrastructure sets for phishing, C2, and data exfiltration, each using different providers and registration patterns. Recorded Future's 2023 analysis of the Chinese group RedHotel showed the same pattern: distinct infrastructure tiers for reconnaissance, operations, and C2, with different providers and geographic distributions for each. The fleet that does phishing looks nothing like the fleet that provides persistent access. OVERCAST could be one segment of a larger operational portfolio.

3. Compromised infrastructure repurposed as operational nodes. Mandiant's May 2024 research on ORB networks (Operational Relay Box networks) documented how Chinese espionage groups build proxy networks from a mix of commercially leased VPS nodes and compromised devices. Some ORBs are entirely "provisioned" (leased VPS), others are "non-provisioned" (compromised routers and IoT devices), and hybrids combine both. The Turla case is the most striking precedent: a joint NSA/NCSC advisory in October 2019 documented Russia's FSB-linked Turla group compromising Iranian APT34 infrastructure across 35 countries, scanning for APT34 backdoors and piggybacking on them for their own operations, without the Iranian operators' knowledge. In this model, an actor gains a foothold on a VPS, standardizes the hostname for operational tracking, and makes RDP available. The windows-{City} naming convention could be an operator's asset management system rather than a provisioning template.

4. Multi-actor convergence. Halcyon's 2023 report documented Cloudzy supporting 17+ nation-state groups across China, Russia, Iran, North Korea, India, Pakistan, and Vietnam, plus ransomware operators and the sanctioned Israeli spyware vendor Candiru. SentinelOne's Hidden Risk report independently confirmed North Korean use of RouterHosting in 2024. When infrastructure is "cheap, easy, and anonymous" (Halcyon's words after purchasing Cloudzy services with only an email and cryptocurrency), multiple unrelated actors will converge on it. The 50 seed IPs may intersect with a much larger fleet operated by a different entity entirely, and the fingerprint overlap may be a C2P provisioning artifact rather than an operational relationship.

5. C2P template overlap. Cloudzy provisions identical templates to multiple customers. The windows-{City} naming, the JARM fingerprints, the certificate pattern: these may be Cloudzy defaults, not operator choices. Multiple unrelated customers could independently produce matching infrastructure without coordination. This is the least dramatic explanation but potentially the most accurate one.

Our Assessment

Our best read: 75% confidence this is C2P/RDP-as-a-Service infrastructure, 60% that multiple actors share it, and 50% that a single APT operates the whole thing. Clean IPs, steady churn, no domains, no payloads: this looks more like infrastructure built to be sold than infrastructure built for a specific campaign.

But it doesn't change what defenders should do. The seed data was validated. The expanded fleet matches the same profile. We flag everything and monitor proactively, because in the C2P ecosystem, waiting for per-IP confirmation is how you miss the intrusion that matters.

Not every asset in the fleet sits neatly in one cluster. 95 IPs, about 5% of the dataset, couldn't make up their mind. They bounced between multiple cluster assignments and every one of them scored above the 95th percentile anomaly threshold. No intermediate severity: these are all critical. An asset is either stable or it's not, and these are emphatically not.

Top 10 Most Anomalous IPs

The three highest-scoring IPs (172.86.69.29, 172.86.116.39, and 216.126.236.155) all score 24.83. Notably, 172.86.116.39 was assigned to 12 different clusters with a label change rate of 0.68, meaning its cluster assignment changed 68%. Its membership entropy of 2.32 indicates near-uniform distribution across those 12 clusters: this asset genuinely belongs to no single operational profile.

Two Patterns of Instability

The Dallas boundary problem (~20 IPs around the largest cluster): These assets got assigned to 12 different clusters, with label change rates of 0.68 and entropy of 2.32. They sit right at the edge between the Dallas primary fleet and neighboring configurations, likely infrastructure in transition, either being reprovisioned or reconfigured.

Small-cluster oscillation (several TLSv1.3 and specialized clusters): A different kind of instability. These IPs bounce between 7-9 cluster assignments with noise frequencies of 0.08-0.23. Their configurations don't cleanly fit any single template, possibly recently spun up or in the process of being decommissioned.

What Anomalous IPs Tell Us

In threat infrastructure, instability usually means one of two things: the asset was recently reprovisioned and hasn't settled into its final configuration, or it's actively being reconfigured for a different purpose. Given the biweekly rotation of ~800 IPs across the fleet, a third explanation fits: some of these anomalous IPs are mid-rotation. They're being decommissioned and replaced, and we're catching them in transit between one provisioning state and the next. Either way, these are the IPs most likely to show up in incident timelines.

Most of the anomalous IPs concentrate in the Dallas primary cluster (the largest) and the TLSv1.3 multi-continent cluster (the one with the most specific fingerprint). That makes sense: they sit at the boundary between fleet tiers, where a configuration change can push an asset from one cluster to another. The anomalies in the TLSv1.3 cluster are the ones worth watching most closely: they're in the newest, most unique part of the fleet, and instability there may signal active deployment or reconfiguration.

One provider, one port, two JARM fingerprints. The detection surface is narrow, but it's well-defined, and that makes it actionable. One thing to keep in mind: with ~800 IPs rotating every two weeks and every one of them scoring clean on reputation services, IP-based detection alone won't cut it. The fingerprint-based rules below are designed to catch the fleet regardless of which specific IPs are active today.

Primary Detection Queries

Full Fingerprint Match:

ssl.cert.issuer.cn:"windows-" ssl.cert.subject.cn:"windows-" port:3389 ssl.jarm:14d14d00014d14d08c000000000000217f0fec773ec97f0b3fdd2de2993c31,26d26d16d26d26d22c26d26d26d26dfd9c9d14e4f4f67f94f0359f8b28f532 ssl.ja3s:6c2811f7ba8e88604ea41a2bf9fa5ad7,649d6810e8392f63dc311eecb6b7098b,ba1b42efc7dc57bb43bf81de59791c1b

With Screenshot Hashes (Highest Confidence):

ssl.cert.issuer.cn:"windows-" ssl.cert.subject.cn:"windows-" port:3389 ssl.jarm:14d14d00014d14d08c000000000000217f0fec773ec97f0b3fdd2de2993c31,26d26d16d26d26d22c26d26d26d26dfd9c9d14e4f4f67f94f0359f8b28f532 ssl.ja3s:6c2811f7ba8e88604ea41a2bf9fa5ad7,649d6810e8392f63dc311eecb6b7098b,ba1b42efc7dc57bb43bf81de59791c1b screenshot.hash:-1311134363,29478602

The difference between the two query tiers reflects the confidence gradient. The full fingerprint match captures all infrastructure matching the TLS and certificate pattern. Adding screenshot hashes narrows to assets where Shodan captured a Windows RDP login screen matching one of two known hashes, one per OS generation (Server 2012 R2 vs. Server 2025), and provides higher confidence at the cost of coverage.

Hunting Guidance

For SIEM/EDR integration, query for outbound connections to port 3389 + ASN 14956 and hunt historically for Windows Event IDs 4624/4625 correlating with source IPs in RouterHosting ranges (172.86.0.0/16, 144.172.0.0/16, 104.194.0.0/16, 216.126.224.0/19, 45.61.128.0/17, 107.189.0.0/16, 167.88.160.0/19). Re-run fingerprint queries at least biweekly: the fleet rotates ~800 IPs every two weeks while maintaining ~1,800 total. Do not rely on reputation feeds for detection: these IPs consistently score clean across major providers. Infrastructure fingerprints are the only reliable detection method.

Why This Matters for OVERCAST

This creates a specific attribution headache: multiple unrelated threat actors buy from the same provider, get the same provisioning templates, and end up with overlapping fingerprints. The windows-{City} naming is Cloudzy's default, not an OPSEC choice. The JARM hashes are Windows RDP signatures, not actor configurations.

What is distinctive about OVERCAST is the scale and the operational discipline. Someone is maintaining ~1,900 RDP VPS instances with standardized configurations, rotating ~800 of them every two weeks, and keeping the entire fleet reputation-clean throughout. Freshly provisioned IPs on a legitimate-looking ASN don't carry baggage: they haven't appeared on blocklists yet, and the steady churn ensures they never accumulate enough abuse reports to trigger reputation scoring. That's not opportunistic abuse. That's sustained procurement with deliberate and diligent lifecycle management.

For All Roles

CRITICAL:

• Do not rely on reputation feeds to detect OVERCAST infrastructure. At the time of analysis, every IP in the fleet scored clean across all major reputation providers. This infrastructure is invisible to reputation-based blocking.
• Block or alert on all RDP traffic (port 3389) to/from AS14956 at your perimeter. This ASN has an estimated 40-60% malicious traffic rate.
• Deploy JARM fingerprint detection for 14d14d... (TLSv1.3) and 26d26d... (TLSv1.2).

HIGH:

• Monitor for outbound RDP to RouterHosting LLC ranges.
• Audit for any historical connections to cloudzy.com or hostnames matching windows-{City}.
• Refresh any IP-based blocklists at least biweekly: the fleet rotates ~800 IPs every two weeks.
• Retain detected IPs on alert/blocklists for at least 90 days (or per your organization's IOC lifecycle policy), even after they stop matching the OVERCAST fingerprint. If this infrastructure serves an IAB function, sold access means the buyer repurposes the IP for staging, C2, or operational deployment: the certificate pattern and JARM change, but the IP address doesn't. The fingerprint-based query caught the IP before it turned; dropping it from monitoring when the fingerprint changes loses the early-warning advantage. Biweekly queries catch new IPs entering the fleet, and the retention window tracks the ones exiting it.

For Threat Hunters

• Search SIEM/EDR for historical RDP connections (Event IDs 4624/4625) to RouterHosting LLC ranges.
• Start with the six most specific cluster signatures: these had no external overlap at the time of analysis.
• The TLSv1.3 multi-continent cluster deserves its own hunt: 72 assets, newest OS, three continents, narrowest fingerprint in the dataset.
• Cross-reference windows-Dubai-2 against any Middle Eastern operational activity in your threat model.
• Check the 95 anomalous IPs against your connection logs: unstable assets tend to be operationally active ones.

For SOC Analysts

• Deploy the detection rules from the previous section for automated alerting.
• Baseline your legitimate RDP traffic to RouterHosting LLC: any connections without documented business justification are suspicious.
• Alert on TLSv1.2 + ECDHE-RSA-AES256-SHA384 cipher to RouterHosting ranges. That combination covers ~75% of the fleet.

For Intelligence Analysts

• Track windows-{City} certificate CN patterns for campaign correlation: it's the most persistent attribution marker, surviving IP rotation.
• Monitor internet scanning platforms for new matches against the six most specific cluster fingerprints.
• Correlate the two JARM fingerprints against threat actor infrastructure databases.
• Watch the TLSv1.2-to-TLSv1.3 migration timeline: it may map to campaign phases.
• Factor the biweekly IP churn into your tracking cadence. Snapshots older than two weeks may contain 40%+ stale indicators.

What the Model Provides

• 40 cluster profiles, each with its own detection fingerprint, ready to match against new infrastructure
• Trained prediction model: feed in IPs you suspect are related to this fleet, and the model classifies whether they match the OVERCAST fingerprint and which cluster they belong to. Available on PROFESSIONAL and ENTERPRISE tiers
• High-specificity signatures, the six narrowest cluster fingerprints from this article, packaged for automated detection

The model is continuously retrained as the fleet evolves or fingerprints change. New provisioning patterns, geographic expansion, OS migration: changes feed back into updated cluster definitions and profiles.

OVERCAST Model Documentation

The full OVERCAST indicator set contains approximately 1,900 IPs. Below is a representative sample across the major network ranges observed in the fleet.

Sample IPs (Selected from ~1,900 total)

RouterHosting LLC ranges (AS14956):

104.194.140.15
104.194.143.127
104.194.143.235
144.172.104.69
144.172.106.158
167.88.165.106
167.88.166.176
172.86.69.29
172.86.91.56
172.86.94.120
172.86.116.39
172.86.117.83
216.126.224.164
216.126.236.155
216.126.237.68
45.61.137.97
45.61.149.100
45.61.157.198

Secondary provider ranges:

107.189.24.38
45.63.14.23
45.63.51.119
5.188.114.82
186.237.140.106
103.75.187.134

Top Anomalous IPs (Highest Priority)

These IPs exhibited extreme membership instability: they represent the most operationally active or transitional assets:

172.86.69.29
172.86.116.39
216.126.236.155
172.86.117.83
216.126.237.68
216.126.236.130
107.189.24.38
167.88.165.106
172.86.117.241
172.86.91.56

Note: OVERCAST infrastructure rotates aggressively. Approximately 800 IPs churn every two weeks while the fleet size holds steady around 1,800. These IPs were active at the time of analysis and scored clean across all major reputation providers. A static blocklist goes stale within days. Use the infrastructure scanner data and hunting queries from this article for ongoing monitoring: the infrastructure fingerprint is the only durable detection anchor.

We started with 50 IPs and a clean attribution label. We ended with 1,900 assets, 40 clusters, and more questions than answers about who's behind them.

The infrastructure is real, actively maintained, and actively rotating: ~800 IPs churn every two weeks while the fleet holds steady at ~1,800. Certificate dates confirm provisioning over a six-month window that's still open. The fleet is structured, not ad hoc. And six clusters produced fingerprints specific enough that no external overlap was found, giving defenders narrow, high-confidence detection signatures to work with.

The attribution tension is worth sitting with. Anonymous cryptocurrency, a provider serving 17+ nation-state groups, no tooling artifacts, no domains: the C2P ecosystem makes it trivially easy to build infrastructure that fingerprints can identify but can't attribute. Whether this is one operator or ten, an APT or an access broker, the answer doesn't change what you should do about it.

Two JARM signatures. One ASN. One port. Block it, hunt for it, and track what happens next.

• Halcyon Research: Cloudzy with a Chance of Ransomware: Command and Control Provider Report (2023) https://www.halcyon.ai/blog/update-cloudzy-command-and-control-provider-report

• SecurityWeek: Iran-Run ISP 'Cloudzy' Caught Supporting Nation-State APTs, Cybercrime Groups (2023) https://www.securityweek.com/iran-run-isp-cloudzy-caught-supporting-nation-state-apts-cybercrime-hacking-groups/

• CISA/NSA/FBI: Russian Foreign Intelligence Service (SVR) Cyber Operations: Trends and Best Practices for Network Defenders (2021, Advisory AA21-116A) https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-116a

• Microsoft Threat Intelligence: Midnight Blizzard: Guidance for responders on nation-state attack (2024) https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/

• SentinelOne / SentinelLabs: BlueNoroff Hidden Risk: Threat Actor Targets Macs with Fake Crypto News and Novel Persistence (2024) https://www.sentinelone.com/labs/bluenoroff-hidden-risk-threat-actor-targets-macs-with-fake-crypto-news-and-novel-persistence/

• NSA/NCSC: Turla Group Exploits Iranian APT to Expand Coverage of Victims (2019) https://www.ncsc.gov.uk/news/turla-group-exploits-iran-apt-to-expand-coverage-of-victims

• Mandiant / Google Cloud: IOC Extinction? China-Nexus Cyber Espionage Actors Use ORB Networks to Raise Cost on Defenders (2024) https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-espionage-orb-networks

• Group-IB: Hi-Tech Crime Trends 2023/2024 (2024) https://www.group-ib.com/landing/hi-tech-crime-trends-2023-2024/

• TRM Labs: 19 Charged Worldwide in Global Cybercrime Investigation of the xDedic Marketplace (2024) https://www.trmlabs.com/resources/blog/19-charged-worldwide-in-global-cybercrime-investigation-of-the-xdedic-marketplace

• Hunt.io: State-Sponsored Activity: Infrastructure Tracking (2024) https://hunt.io/blog/state-sponsored-activity-gamaredon-shadowpad

• Silent Push: Russian APT Infrastructure Analysis (2024) https://www.silentpush.com/blog/from-russia-with-a-71/

• MITRE ATT&CK: Russian State-Sponsored Threat Groups https://attack.mitre.org/groups/

• ThreatFox: AS14956 IOC Listings https://threatfox.abuse.ch/asn/14956/