One clean RDP login to Lynx ransomware: why no failed logins is the warning

The Lynx ransomware intrusion did not start with a break-in. It started with a login. A single successful RDP logon to an internet-exposed host, from an unfamiliar source, with no brute force, no credential stuffing, and no failed authentication before it. The credential worked on the first try. Hours later Lynx was encrypting.

The reflex when you see a ransomware intrusion trace back to RDP is to close RDP and block the source IP. That is the wrong lesson. The interesting fact here is what is missing from the logs, and what its absence tells you about where the intrusion really began.

How it works

The entry needs no exploit. An internet-exposed RDP surface accepts a valid credential, and the actor has one. From that foothold they read LSASS and harvest cached credentials (T1003, OS Credential Dumping) to widen access beyond the single account they logged in with. They move over RDP and SMB to more hosts (T1021, Remote Services), staging for a domain-wide deployment. Before encrypting, they delete Volume Shadow Copies (T1490, Inhibit System Recovery) so local restore is off the table, then run the Lynx encryptor (T1486, Data Encrypted for Impact). As with most modern ransomware, data is stolen before it is encrypted, so a leak threat exists even if you restore.

The whole chain hangs on the first event: a valid account used cleanly at the door (T1078, Valid Accounts, over T1133, External Remote Services).

Why a clean login is the warning

Password guessing is loud. Brute force and credential stuffing leave a trail of failed-logon events before one finally lands: a burst of 4625s, lockouts, retries. That noise is what most detection is tuned to catch.

Here there is none of it. One 4624 type-10 success from an unusual IP, and nothing before it. A first-try success with no failed-auth history does not mean the attacker got lucky. It means they were not guessing. The credential was already valid when they used it, which means it was stolen somewhere else first, most often from an infostealer log or bought from an access broker who harvested it.

That inverts the usual signal. The absence of brute-force noise is itself the indicator. A clean, quiet, first-try remote login from an unusual source is more alarming than a noisy failed one, because it points at a credential that leaked outside your walls.

How to detect it

Do not only alert on failed-logon bursts. Alert on the clean success that has no business being clean: a successful RDP logon (4624 type 10) from an unfamiliar source IP with no preceding failed-logon (4625) events from that source, especially outside normal patterns. Correlate it forward: an LSASS read on that same host minutes later, then logons from it to hosts it never talks to. The authentication log is authoritative for how the actor got in. A 4624 success with no 4625 trail is your evidence the credential was pre-stolen, not cracked.

How to contain and shut it down

This is the part teams get wrong. Blocking the source IP and disabling RDP on the one host feels like containment. It is not. The attacker holds a valid credential, and that credential still works everywhere it is valid. They return from a new IP, or through another exposed service, with the same login.

Containment means invalidating the key, not closing one door:

• Disable and rotate the exposed credential everywhere it is valid, and revoke its sessions.
• Isolate the foothold and every host reached with harvested credentials, before the encryptor is staged.
• Open a hunt for the leak origin. Search infostealer-log and access-broker sources for the exposed identity, and rotate any other workforce credentials that show up there.
• Remove the direct internet exposure and put remote access behind a gateway or VPN with MFA, so a stolen password alone can never log in again.

Then recover honestly. The shadow copies were deleted on purpose, so restore from offline or immutable backups, and only after eradication is real. Because Lynx steals data before encrypting, treat this as a likely data-theft and double-extortion event, and scope notification by data type and jurisdiction. The credential leaked outside your environment, so the blast radius is every system it and the harvested credentials can reach, not one server.

Practice it

We built this as a scenario in GraphLattice Range: a single clean RDP logon with no failed-auth trail, leading to credential access, lateral movement, shadow-copy deletion, and Lynx deployment. It forces the non-obvious call under time pressure. Block the IP and close RDP and feel contained, or recognize that a first-try login means a stolen credential and rotate it everywhere while you hunt the leak. Teams that make that call in a drill make it faster when it is real.