A Login Nobody Initiated

Once upon a time in a incident response engagement, we discovered an unusual root cause for an otherwise run-of-the-mill ransomware attack. In the middle of the night, a non-production server belonging to an APAC-based Financial Institution accepted an inbound AnyDesk connection. Access (mysteriously) granted, the incomer proceeded with internal reconnaissance to kick off the standard operating procedures of a ransomware attack.

What initially appeared as a simple ransomware case initiated via credential compromise turned into the discovery that malicious actors are weaponising legitimate features in AnyDesk for initial access. This reiterates the growing attack surface exposure facing enterprises; as threat actors seek less obvious vectors with limited defensive visibility.

This blog delves into our research whereby this pattern linked multiple campaigns to a persistent ecosystem of attacker-controlled Windows VM templates, Russian-linked threat infrastructure, and a bruteforce pipeline that had been running since at least 2023 and remains active as of August 2026.

TL;DR

• Russian-linked initial access brokers are actively abusing attacker-controlled Windows VM templates (e.g. WIN-J9D866ESIJ2, WIN-LIVFRVQFMKO, WIN-BS656MOF35Q) hosted on bulletproof providers such as Stark Industries and WorkTitans.
• In multiple APAC incidents, attackers gained access via AnyDesk using the exact same password as the local administrator account, often with little to no visible brute-force activity visible in traditional monitoring.
• The infrastructure remains fully operational in 2026, despite international sanctions and multiple ASN migrations.
• Compromised footholds from these templates are regularly sold or used to deliver Black Basta, LockBit, BlackNevas, and other ransomware families.
• These templates are not limited to AnyDesk brute-force — they are heavily used for RDP, WinRM, SMB, SSLVPN, credential harvesting, port scanning, and direct ransomware deployment.

Why AnyDesk Is a Target

AnyDesk is a lightweight remote monitoring and management (RMM) tool deployed widely across enterprise environments, managed service providers, IT support teams, and – increasingly – threat actors.

One of the favored features is “Unattended Access“, which allows remote connections without any local user action. This is operationally convenient: it enables remote access without the complexity of SSL VPN. In practice, unattended access passwords are often set to match local admin credentials for convenience – a pattern we would come to see exploited systematically.

AnyDesk can operate behind corporate firewalls through relay servers, or it can be exposed directly to the internet via port 7070. Censys data indicates more than 230,000 AnyDesk assets exposed globally, each one a bruteforce target.

Every exposed AnyDesk installation becomes an attack surface. If no lockout mechanism, no rate limiting, and critically – no Windows logging of failed authentication attempts – are in place, attackers can conduct silent, large-scale credential testing.

How AnyDesk Works: Understanding the Attack Surface

To many, AnyDesk is a remote software that we connect with an AnyDesk ID. Under the hood, AnyDesk has different connection routing and authentication mechanisms, shown below:

Registration and Discovery: When AnyDesk initialises, it registers with AnyDesk’s signaling servers (boot.net.anydesk.com) to obtain a unique 9- to 10-digit identifier. This identifier functions as a directory service, brokering connections between clients without revealing their network topology.

From that point, AnyDesk tries to establish connection in one of the two ways.

1) Direct Connection: AnyDesk attempts direct peer-to-peer connection first. By default, the receiving end has TCP port 7070 open to allow for inbound connection. This is enabled by “Allow Direct Connections” setting in AnyDesk. In local network scenarios, AnyDesk uses multicast discovery on UDP 50001-50503. For remote connections across NAT, both parties exchange public IP addresses and ports via AnyDesk’s signaling infrastructure — a mechanism analogous to STUN (Session Traversal Utilities for NAT).

Line-of-sight

The simplest case is when both machines are in the same network. AnyDesk can use the local discovery feature through conducting multicast traffic to 239.255.102.18 on UDP 50001-50003. A direct connection on TCP port 7070 would help ensure the best connection quality; there is no AnyDesk servers relaying session data.

When there’s NAT in the way

What happens when one or both parties sit behind a router or network device? The data stored by AnyDesk’s server would coordinate the connection using a technique known as hole punching. Both connecting and receiving parties would receive the public IP addresses and ports as observed by AnyDesk’s servers, before simulatenously sending each other traffic to initiate a connection. The avid reader would recognise this technique shares similarity to Session Traversal Utilities for NAT (STUN).

Worth noting, this mechanism has introduced vulnerability CVE-2024-52940, in which a connecting party is able to leak the target’s public IP address simply by probing the victim with the AnyDesk ID alone.

2) Relay Connection: When direct connections fail – the standard case in enterprise networks with restrictive egress filtering – AnyDesk falls back to relay mode. Both clients establish outbound connections to AnyDesk’s relay servers (*.net[.]anydesk[.]com) on TCP 80, 443, or 6568. The relay servers forward encrypted session data between clients.

Why this matters for exploitation: Direct connections expose the attacker’s real IP address to the target. In our investigations, bruteforce activity consistently used direct mode, inadvertently revealing attacker infrastructure to defenders monitoring outbound TCP/7070 traffic. This visibility gap was critical to attribution.

Local discovery:

Unattended Access: The Interesting Feature

Unattended access is the feature that transforms AnyDesk from a tool of convenience into an attack surface. When enabled, AnyDesk accepts incoming sessions without requiring local user interaction. Authentication is solely password-based by default.

In most deployments we encountered, AnyDesk was installed for tactical reasons: vendor access for one-off projects; IT administrators on leave; SSLVPN perceived as too slow.

To make matters worse, often, Unattended Access passwords were routinely set to match local admin credentials for convenience. This means that when a threat actor successfully brute forces an AnyDesk exposure, they could subsequently re-use the same password to authenticate as a local administrator on the system – appearing to defenders as a legitimate login with valid credentials.

This is precisely the pattern we observed in our incident response engagements – prompting us to consider – how could we simulate this attack?

Why this matters operationally: the abuse of AnyDesk appears as a legitimate authentication. Standard detection rules for “suspicious remote access” only fire on the tools, and when the password is correct, Windows logs it as a normal logon event. This authentication-visibility gap enabled the pipeline to operate undetected across multiple targets.

The Bruteforce Workflow

AnyDesk’s command-line interface renders this attack fully scriptable. The attack chain proceeds in four discrete steps:

Step 1 – Target Discovery: Attackers assemble target lists of internet-exposed AnyDesk installations via Censys or Shodan. Both platforms index AnyDesk service banners and publish AnyDesk IDs or IP addresses for hosts with port 7070 or 6568 open. A single Censys query yields tens of thousands of candidates globally in seconds.

Our research also shows possibilities to use side-channel mechanism to determine if an AnyDesk ID is alive. A massive scan is possible to conduct an enumeration of AnyDesk that are alive on the Internet, and as we can see, threat actors have already done something similar.

Step 2 – Credential Assembly: Password combo lists are prepared – seeded with common defaults, leaked databases filtered by target geography or industry, and permutations of standard admin usernames.

Step 3 – Scripted Bruteforce: The attacker iterates through targets, piping each password candidate through the AnyDesk CLI:

echo <candidate_password> | anydesk.exe <TARGET_ID_OR_IP> --with-password.

AnyDesk returns silent success or failure.

Why this scales without detection: No lockout mechanism exists in standard AnyDesk; No rate limiting; Critically – No Windows Security log entries for failed AnyDesk authentication attempts. An attacker can test thousands of credentials against a single target without triggering conventional SIEM rules. This operational advantage is what enables the pipeline to function at scale.

POC:

Step 4 – Post-Exploitation: Successful matches yield full interactive desktop sessions. Upon successful bruteforce, the attacker gains interactive access, enabling lateral movement, credential theft, or direct ransomware deployment—all while appearing in Windows logs as legitimate administrator activity. The window between initial access and full compromise typically spans hours, not days.

The Infrastructure Ecosystem

The infrastructure enabling these attacks follows a consistent pattern. In early 2025, Sophos and Censys separately documented a recurring pattern in bulletproof hosting infrastructure: Windows VM templates with identical hostnames distributed across thousands of IPs at abuse-tolerant hosting providers. The most prominent identifiers: WIN-J9D866ESIJ2, WIN-LIVFRVQFMKO, WIN-BS656MOF35Q.

These templates exhibited structural consistency: RDP on port 3389, identical JA4 TLS fingerprints, and reproducible VM image reuse across hosting providers and ASNs. Observed activities spanned ransomware deployment, RMM bruteforce, C2 hosting, port scanning, and credential harvesting.

This is the same infrastructure we were tracking across our APAC incident investigations. We directly matched source IPs from AnyDesk bruteforce activity in our APAC cases against this documented infrastructure. Notably, we could identified number of suspicious VM templates were actively scanning AnyDesk during the same period (September 2024- June 2025):

Hosting Infrastructure

The following summarises the key hosting providers observed enabling this bruteforce activity, based on our analysis and existing open-source reporting:

Campaign Timeline

Who’s infrastructure is this anyway?

The VM template infrastructure has been attributed to Russian-linked threat actors in Sophos and Censys research, primarily through ASN affiliation with Stark Industries Solutions Ltd – a bulletproof hosting provider with documented ties to Russian cybercriminal and state-adjacent activity, subject to US OFAC sanctions.

We assessed with high confidence that the AnyDesk bruteforce activity in our APAC engagements originated from this infrastructure cluster. This was based on the following considerations:

• Source IPs in incident data match WIN-J9D866ESIJ2 and WIN-LIVFRVQFMKO infrastructure documented in external research
• Attack timing and tooling consistent with published campaign windows
• Ransomware groups (Black Basta, LockBit, BlackNevas) align with known affiliates operating through Stark Industries-hosted infrastructure, and are reported to be of Russian origin (in terms of RaaS operators)

Ransomware Outcomes and Operational Evolution

The suspicious VM templates have served as confirmed initial access in at least three ransomware campaigns linked to this infrastructure cluster:

• Black Basta: Deployed following AnyDesk bruteforce from WIN-J9D866ESIJ2 (September 2024 – February 2025)
• LockBit: Deployed in overlapping campaign period using the same VM template infrastructure
• BlackNevas: Deployed December 2025 – February 2026, following FortiGate SSLVPN compromise also attributable to WIN-LIVFRVQFMKO and WIN-J9D866ESIJ2 infrastructure — indicating the operators pivoted from AnyDesk to unauthorized access of SSLVPN as a secondary access vector

We have also observed similar AnyDesk abuse patterns outside the primary VM template cluster. In June 2026, operators behind the GodDamn ransomware — a rebrand of the Beast/Monster lineage — deployed AnyDesk from non-standard directories such as the Music folder and registered it as persistent Windows services. They combined it with a Microsoft-signed malicious kernel driver (PoisonX) to disable endpoint defenses before encryption. While this case does not appear directly linked to the WIN-J9D866ESIJ2 infrastructure we track, it reinforces that AnyDesk remains actively abused by Russian-linked operators well into 2026.

Operational Implications: The operators demonstrate no fixation on AnyDesk specifically. They execute systematic credential-testing operations against whichever RMM or VPN service is most accessible on a given target. As enterprises harden individual services, operators transition to the next accessible vector. The tool changes; the operational playbook persists.

Conclusion: What This Signals About the Future

The AnyDesk bruteforce campaign documented here is not novel in technique — it has operated in some form since 2023. Its significance in 2026 lies in its persistence, operational adaptation, and what it signals about the trajectory of RMM-based initial access as a sustained threat vector.

The operators behind WIN-J9D866ESIJ2 and the broader Stark Industries infrastructure cluster have demonstrated a repeatable operational playbook: maintain stable, abuse-tolerant hosting infrastructure; execute systematic credential-testing operations against whichever remote access service is exposed; deploy ransomware affiliates against successful compromises; adapt infrastructure and tactics as defenders strengthen individual services.

We anticipate this pattern will extend to other RMM tools — TeamViewer, ScreenConnect, and MSP-specific remote access agents — as enterprises harden the most commonly targeted surfaces. Any internet-exposed RMM or VPN service should be classified as a high-priority attack surface, not a convenience tool.

Immediate action is warranted: Organisations in APAC’s financial services, logistics, and critical infrastructure sectors should audit all internet-exposed RMM deployments, implement the hardening guidance below, and treat any unexpected RMM access as a potential compromise.

We will continue monitoring this infrastructure cluster. Organisations with telemetry on WIN-J9D866ESIJ2 or WIN-LIVFRVQFMKO activity not covered in this post are encouraged to contact us via the DarkLab disclosure channel.

Recommendations

For Security Teams

The following recommendations are prioritised by the specific techniques observed in this campaign. Generic hardening advice that does not map to observed attacker behaviour has been excluded.

• Audit all AnyDesk deployments immediately. Enumerate every host with AnyDesk installed in your environment. Flag any installation where unattended access is enabled and the password matches or is derived from the local admin account. This is the exact credential reuse pattern exploited in our APAC cases.
• Deploy alert rules for AnyDesk CLI abuse. Hunt for 4688 process creation events where anydesk.exe is spawned with --set-password, --install, or --silent arguments. These are not legitimate administrator patterns.
• Alert on outbound TCP/7070 to non-anydesk.com destinations. This reveals direct-mode connections and will expose the attacker’s real IP before relay mode takes over.
• Block or tag traffic to Stark Industries ASNs (AS209847, AS44477) and Dynu Systems (AS398019). These ASNs have no legitimate business traffic justification for most enterprise environments.
• Implement AnyDesk Access Control Lists (ACLs). Restrict which AnyDesk IDs are permitted to connect to your endpoints. Most environments have a finite set of legitimate administrator IDs — anything outside the whitelist should be blocked.
• Verify connection_trace.txt on servers with AnyDesk. Look for Passwd or Token authentication entries from unexpected AnyDesk IDs. If you find these on a server with no corresponding support ticket, treat it as a confirmed incident.
• Search your SIEM for WIN-J9D866ESIJ2 and WIN-LIVFRVQFMKO across all log sources. Any match — in DNS queries, proxy logs, authentication logs, or endpoint telemetry — warrants immediate investigation.

For IT Administrators and End Users

If AnyDesk is deployed in your environment for legitimate purposes, the following hardening steps directly address the techniques used in this campaign:

• Never set the AnyDesk unattended access password to match any other account credential. Use a unique, randomly generated password of at least 16 characters stored in a password manager.
• Disable unattended access when not in active use. Enable it only when an attended session is required and disable it immediately after.
• Disable Local Discovery (multicast on UDP 50001-50003). This feature is unnecessary for most deployments and aids lateral movement if an attacker reaches the internal network.
• Disable “Online Visibility” in AnyDesk settings. This prevents your installation from being indexed by AnyDesk’s own directory — reducing your visibility to attackers who search AnyDesk’s own network.
• Install AnyDesk per-user, not system-wide, where operationally possible. System-wide installations run as a service and persist across reboots; user-level installations require active user sessions.
• Restrict AnyDesk permissions. Disable file transfer, clipboard sharing, and remote printing unless explicitly required. Limit the blast radius of any successful compromise.
• Enable auto-disconnect for inactive sessions. A session that has been idle for more than a defined period should terminate automatically.

MITRE ATT&CK Mapping

ATT&CK Mapping

The following TTPs cover the observed attack chain from initial access through to ransomware deployment:

Indicators of Compromise

IP Addresses

Hostnames / VM Template Identifiers

Malicious Infrastructure ASNs

Detection Opportunities

Distinguishing malicious AnyDesk activity from legitimate use is challenging but not impossible. The attack leaves a distinct forensic footprint if you know where to look.

Network Indicators

The most actionable network signal is outbound TCP port 7070. When AnyDesk establishes a direct connection (as opposed to relay), it uses port 7070 and the destination is the attacker’s real IP — not an anydesk.com relay. Alert on any outbound TCP/7070 to non-anydesk.com destinations, particularly from servers that have no business need for remote desktop tools.

Relay-mode traffic is harder to distinguish from legitimate AnyDesk use, as it transits *.net.anydesk.com. Look for relay traffic originating from servers rather than workstations — AnyDesk relay connections from servers in your environment should be treated as suspicious unless explicitly authorised.

Block or alert on traffic to known malicious infrastructure ASNs:

• AS209847 (WorkTitans B.V. / Stark Industries post-migration)
• AS398019 (Dynu Systems)
• AS215826 (Partner Hosting)

Windows Event Log Indicators

For hosts where AnyDesk was silently installed by a threat actor (rather than being a pre-existing deployment), the following events indicate malicious installation:

AnyDesk Log Artefacts

The following AnyDesk log files should be reviewed during incident response. On Windows, they are typically located under %ProgramData%\AnyDesk\ or %APPDATA%\AnyDesk\:

• ad.trace / ad_svc.trace — verbose connection logs including source IDs and connection timestamps
• connection_trace.txt — summarises successful and failed connections; look for unexpected Passwd or Token authentication entries indicating unattended access was used
• system.conf — contains the configured unattended access password hash; compare against known-good configuration
• thumbnails / directory — stores screenshots taken during sessions; can confirm attacker activity even when other logs have been cleared

Sigma Rule

title: Suspicious VM Template Hostname - Login Activity
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: >
  Detects logon activity related to suspicious VM template hostname.
author: PwC Darklab
date: 2026-04-28
modified: 2026-04-29
references:
  - https://attack.mitre.org/techniques/T1078/
  - https://attack.mitre.org/techniques/T1021/002/
tags:
  - attack.lateral_movement
  - attack.initial_access
  - attack.t1078
  - attack.t1021.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4624
      - 4625
      - 4776
    WorkstationName|contains:
      - 'WIN-J9D866ESIJ2'
      - 'WIN-LIVFRVQFMKO'
      - WIN-BS656MOF35Q'
  condition: selection
fields:
  - EventID
  - WorkstationName
  - IpAddress
  - LogonType
  - TargetUserName
  - Status
  - SubStatus
falsepositives:
  - well-known-bad IOC; no expected false positives
level: high