Exposed RDP and password spray to ransomware: the failed logins are the warning

This intrusion began the loud way. An RDP server was published straight to the internet, with no gateway and no MFA, and an attacker sprayed it. Not a targeted brute force against one account, a spray: many usernames, a few common passwords, running for hours. Eventually one account worked, the attacker logged in over RDP as a real user, and hours later RansomHub was encrypting.

The reflex when a ransomware case traces back to RDP is to reset the one account that got popped and move on. That is the wrong lesson. The interesting thing here is what the logs show you before the success, and what it tells you to do about it.

How it works

The entry needs no exploit. An internet-facing RDP surface (T1133, External Remote Services) accepts logins from anywhere, so the attacker runs a password spray against it (T1110, Brute Force). Spray is a volume game: cycle a large list of usernames against a small set of common passwords, stay under per-account lockout thresholds, and let the internet give you unlimited attempts. After enough tries, one weak or reused password lands.

That single success is a valid-account logon (T1078, Valid Accounts). The attacker is now inside as a real user, over RDP. From there they enumerate the domain, harvest more credentials from reachable hosts, and move laterally over RDP (T1021, Remote Services) to widen access well beyond the one sprayed account. Before encrypting, they delete Volume Shadow Copies and disable recovery (T1490, Inhibit System Recovery) so local restore is off the table, then run the RansomHub encryptor. As with most modern ransomware, data is accessed before it is encrypted, so a leak threat exists even if you restore.

Why exposed RDP keeps winning for attackers

Exposed RDP is a standing invitation, and spray is the cheapest way to accept it. Internet scanners find every open 3389 in minutes. Against a single account, lockout policy blunts guessing. Against the whole account base, spray sidesteps lockout by trying each account only a few times, and the attacker only needs one weak or reused password across your entire directory to succeed.

So the odds favor the attacker as long as the endpoint is reachable. Reset the one account that fell and the spray simply continues against the others. Change the port and the scanners still find it. The volume game only ends when there is no exposed endpoint to spray, which is why removing the exposure, not hardening one password, is the actual control.

How to detect it

Unlike a quiet stolen-credential case, where a single clean login is the only tell, this attack announces itself in the authentication logs. The signal is a wall of failed logons: a high volume of 4625 events fanned out across many distinct usernames, from a small set of source IPs, with logon type 10 (RDP), and then one 4624 success on one of those accounts.

That breadth across usernames is what separates spray from brute force. Brute force hammers one account until it locks out; spray spreads thin across many accounts to stay under the threshold. Alert on the volume and the fan-out, not on any single failure. Then correlate the success forward: the 4624 that follows the spray, credential-access activity on that host minutes later, and logons from it to hosts it never talks to. The failed logins are your warning, and unlike the quiet case, they arrive before the success.

How to contain and shut it down

This is the part teams get wrong. Resetting the one sprayed account and blocking the source IPs feels like containment. It is not, for two reasons: the endpoint is still exposed, so the spray moves to other accounts, and the attacker is already inside as a real user, so the reachable estate is in play.

Contain the exposure and the credential base together:

• Disable and rotate the sprayed account, and block the spraying source IPs.
• Remove RDP from the public internet. Put remote access behind a VPN or RD Gateway that enforces MFA, so a sprayed password alone can never log in again.
• Treat every RDP-reachable host and every credential the attacker could have touched as suspect, and rotate them. Once a sprayed credential works, the blast radius is the reachable estate, not one account.
• Enable lockout and spray detection on the authentication logs so the next 4625 burst pages someone.

Then recover honestly. The shadow copies were deleted on purpose, so restore from offline or immutable backups, and only after the exposure is removed and the credential base is rotated, or you restore straight back into the same open door. Because the attacker had hands-on access to reachable file shares before encrypting, treat this as a potential data-theft event, and scope notification by data type and jurisdiction rather than assuming it was only an availability problem.

Practice it

We built this as a scenario in GraphLattice Range: an internet-exposed RDP endpoint sprayed until one account works, leading to credential access, lateral movement, shadow-copy deletion, and ransomware deployment. It forces the non-obvious call under time pressure. Reset the one account and keep watching, or recognize the 4625 volume for what it is, remove the exposure, and scope the whole credential base as burned. Teams that make that call in a drill make it faster when it is real.