Removing an RDP-Spreading Worm from a Windows Computer

A Remote Desktop worm exploits open RDP ports to jump from one Windows host to the next, often by brute-forcing weak administrator passwords or reusing credentials harvested from earlier intrusions. Once inside a network, it scans for other machines with port 3389 open and repeats the process, turning a single compromised server into a launchpad for lateral movement. Because the worm rarely needs a user to click anything, it is a favourite vector for operators who want to spread quietly across offices, retail branches and home offices alike.

In Australia, the shift to hybrid work has left many small businesses in suburbs from Parramatta to Fortitude Valley exposing RDP directly to the internet, sometimes through a consumer-grade router with no port-forwarding rules at all. ACSC advisories have repeatedly warned that exposed RDP endpoints are among the most common entry points observed during local incident-response engagements. A worm that rides this pathway can therefore reach accountants in Adelaide, tradies running a warehouse in Perth and remote engineers in Hobart with very little effort.

Cleaning such an infection is not as simple as running an antivirus scan, because the malware usually drops multiple components and creates new local accounts to keep its foothold. The process combines network-level isolation, account auditing and credential rotation, followed by careful removal of the worm payload. The steps below walk through what an Australian technician, IT volunteer or experienced home user should do when this scenario plays out on a Windows 10 or Windows 11 machine.

Tracing the Worm's Path Through Exposed RDP

Most RDP-spreading worms rely on one of two strategies: dictionary attacks against the Administrator account, or reusing passwords stolen by info-stealers from another breach. The worm typically runs as a Windows service on the first machine it compromises, then uses native RDP client libraries to authenticate to neighbouring hosts. Australian SMBs running older Windows Server 2012 R2 builds or unpatched Windows 10 endpoints are frequent first targets, especially when staff in regional towns connect back to head office over consumer NBN links.

When it lands on a new system, the worm usually performs several hostile actions in quick succession. It disables Windows Defender real-time protection, opens firewall rules for inbound RDP from any address, and creates a hidden local user such as sqlsvc$ or helpdesk$ added to the Remote Desktop Users group. Some variants also drop secondary payloads, including stealers and even ransomware loaders delivered as a follow-on stage. Comparing these behaviours side by side helps responders triage what they are dealing with before wiping anything.

Behaviour	Typical RDP worm	Ransomware payload	Stealer-only payload
Scans port 3389 on the LAN	Yes	Sometimes	Rarely
Creates hidden local RDP user	Yes	Often	No
Drops second-stage binary	Common	Always	No
Encrypts user files	No	Yes	No
Harvests browser credentials	Sometimes	Sometimes	Yes

For defenders, recognising these patterns early is critical. A quick review of the local SAM database, the list of installed services and the contents of C:\ProgramData often reveals which of the three profiles a machine matches.

Cutting Off the Worm's Lateral Movement

Before touching the infected host, the priority is to stop the worm from spreading further across the network. If you are handling the incident from a Sydney or Melbourne office, disconnect the machine from Wi-Fi and Ethernet but leave it powered on so volatile evidence in RAM can still be reviewed later. For businesses running Active Directory, place the computer account in a dedicated quarantine OU and disable its account so it cannot authenticate to file shares, print servers or domain controllers.

RDP exposure should be addressed at the network edge as well. Block inbound TCP 3389 on the perimeter firewall, or at minimum restrict it to a small allow-list of static IPs used by staff who genuinely need remote access. Many Australian managed-service providers now route RDP through a VPN or a jump host sitting inside an Azure Sydney region, which removes the public attack surface entirely. If a jump host is not feasible in the short term, Microsoft LAPS for local administrator passwords reduces the value of any credentials the worm already has.

It is also worth checking whether the worm has piggy-backed a stealer onto the infected host, because harvested passwords are often reused across Microsoft 365, MYOB and banking portals common to Australian small businesses. Following a ransomware payloads overview can help responders tell whether the infection is a worm stage alone or part of a larger extortion chain. Resetting every password that ever touched the compromised machine, including service accounts, closes that loop.

Cleaning an Infected Windows Endpoint

With the host isolated, the cleanup itself can begin. Boot into Safe Mode with Networking so the worm's persistence mechanisms do not load, then run an offline scan using a second-opinion engine such as Malwarebytes or ESET's online scanner alongside the built-in Windows Defender. Review the following locations manually, since some worm families bury themselves in places that signature-based tools miss:

• C:\Windows\System32\drivers for unsigned .sys files added in the past 30 days
• Scheduled Tasks under \Microsoft\Windows\Active Directory Helper and similar hidden paths
• Registry run keys under HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• The Remote Desktop Users group for any account you did not create yourself

If a keylogger or credential harvester is suspected on top of the worm, follow a dedicated keylogger removal guide once the worm itself has been removed, because the two threats require different forensic checks. After manual cleanup, re-enable Windows Defender, install any pending cumulative updates and reboot twice to confirm the infection does not reappear in the Task Scheduler queue.

Auditing Accounts, Shares and Persistence

Removing the worm's files is only half the job, because the hidden accounts and shares it created will quietly wait for the operator to return. Open lusrmgr.msc and delete any user that was not added by your IT team, paying particular attention to accounts with a dollar sign in the name or with passwords set to never expire. Audit the local Administrators group, the Remote Desktop Users group and any custom groups your business uses for finance or HR software, then reset the password of every legitimate account on the host.

Network shares deserve a similar pass. Worms frequently map hidden administrative shares such as C$ or ADMIN$ to move tooling across machines, so confirm that share-level permissions match the principle of least privilege. For Australian organisations subject to the Notifiable Data Breaches scheme under the Privacy Act 1988, a documented audit of every account touched by the worm is also useful evidence if the incident later needs to be reported to the Office of the Australian Information Commissioner.

Finally, review Group Policy and registry settings for persistence. Worm authors often add a RunOnce key pointing to a dropped executable, or modify the Winlogon Shell value to load a fake explorer.exe from AppData\Roaming. Removing these entries requires a careful diff against a known-clean baseline, so capturing a registry export before cleanup begins is a wise precaution.

Preventing the Next RDP Worm

Long-term protection starts with closing the door the worm walked through. Disable RDP on any machine that does not strictly require it, and on the machines that do, require Network Level Authentication and a complex, unique password for every account allowed to log in remotely. Rolling out Windows Defender Credential Guard on supported hardware blocks the kind of password theft that many worms depend on for lateral movement.

For Australian businesses aiming to align with the ACSC Essential Eight, enforcing application control, patching internet-facing systems within two weeks and restricting administrative privileges all reduce the impact of an RDP worm significantly. Combining those practices with multi-factor authentication on every remote-access account, including vendor and contractor logins, makes brute-force attempts against port 3389 essentially worthless. A modest investment in configuration is usually enough to keep this entire class of malware off the network for good.