From Exposed RDP to Domain Encryption: Auditing Your Stack Against the Conti Playbook

Why the Conti sentencing is useful only if you turn it into a control review

The reporting says a Conti ransomware member was sentenced after the group attacked more than 1,000 victims worldwide. That part is news. The security value is in the failure chain it reflects: exposed remote access, privilege drift, lateral movement, and domain-wide encryption still show up in real environments.

My position is simple: if a Conti-style crew can move from internet-facing remote access to domain encryption in your stack, the architecture is already too trusting. The sentence is the headline; the useful work is the audit you run afterward.

What the reporting confirms about the group’s scale and history

Confirmed by the reporting: the case is tied to Conti, and the group is described as having attacked over 1,000 victims worldwide.

Confirmed by earlier public analysis of Conti-style incidents: this is not a one-host problem. It is a chain problem. Initial access, privilege escalation, lateral movement, and encryption all depend on the previous control failing in a pretty ordinary way.

That matters because a lot of teams still treat ransomware as a malware detection problem. It is not. By the time encryption starts, the attacker has often already won identity, reachability, and recovery.

What we should treat as inference when mapping the playbook to our own stack

Inference: if your environment has the same exposed surfaces and identity drift that Conti crews historically leaned on, you should expect the same class of failure even if the actor is different.

Inference: your initial access route may not be RDP. It could be VPN reuse, stolen session cookies, phishing, or a misconfigured admin tool. But once the attacker gets a foothold, the rest is usually routine and well practiced.

That is why I do not care much about the sentence itself as a security lesson. I care about whether your controls would stop the same chain tomorrow morning.

The first mistake in the chain: exposing RDP to the internet

How exposed remote access turns brute force, credential stuffing, and reused passwords into initial access

Public RDP is still one of the easiest ways to turn an identity mistake into a breach.

The pattern is boring:

• the host listens on 3389 or a forwarded equivalent
• authentication is reachable from the internet
• passwords are reused, weak, or already known from another breach
• MFA is absent, bypassed, or only partly enforced
• the account has enough privilege to matter

Once that is true, you do not need a novel exploit. You need time, noise tolerance, and credentials that eventually land.

This is why exposed remote desktop is not “just a perimeter issue.” It is an identity problem that happens to show up on the network.

A quick defensive check on Windows looks like this:

Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 3389 }

If this returns a listener on a host that should never accept inbound RDP, you have a problem. If the host is also reachable from the internet, the problem is bigger.

A slightly broader reachability check from a management host:

Test-NetConnection -ComputerName <host-or-ip> -Port 3389

Example output that should make you pause:

ComputerName     : 203.0.113.45
RemoteAddress    : 203.0.113.45
RemotePort       : 3389
TcpTestSucceeded : True

That does not prove compromise. It proves exposure.

What to check in perimeter logs, VPN gateways, and remote desktop access policies

If you want to know whether remote access is under pressure, look for these patterns:

• repeated 4625 logons with the same source or the same target account
• logons at odd hours from unfamiliar geographies
• bursts of successful logons after many failures
• VPN sessions that immediately pivot to administrative hosts
• RDP allowed from broad network ranges instead of named jump points

Useful Windows event IDs include:

• 4624 for successful logons
• 4625 for failed logons
• 4634 for logoff
• 4776 for NTLM authentication validation
• 4778 and 4779 for RDP reconnect/disconnect patterns

A simple hunt in PowerShell:

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4625,4776,4778,4779
  StartTime=(Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, ProviderName, Message | Format-List

You are looking for concentration, not perfection. One failed login is normal. A thousand failures against a handful of privileged accounts is not.

Safer patterns: bastions, zero trust access, MFA, and account-level restrictions

The fix is not “hide RDP a little better.”

Use:

• bastion hosts or jump boxes with strict allow lists
• MFA on every remote entry point
• zero trust or per-app access instead of flat inbound access
• separate admin accounts for admin work
• account-level restrictions so privileged accounts cannot log on everywhere

The biggest win is usually the least exciting one: remove direct inbound RDP from user endpoints entirely. If a server has to be reachable, make it reachable only from a hardened access tier.

Why the real failure is usually identity, not the first login

The privilege-escalation paths Conti-style operators tend to exploit in Windows environments

Once an attacker gets one valid session, the next question is not “can they run malware?” It is “what else can this identity touch?”

In Windows environments, the common escalation paths are predictable:

• local administrator rights on too many endpoints
• service accounts with interactive logon ability
• domain groups that grew by convenience instead of design
• delegated admin rights that were never revisited
• shared credentials across teams or scripts
• stale accounts that still have access to critical systems

Conti-style operators do not need anything fancy here. They need one admin path that was left open because operations depended on it.

Where admin sprawl, shared accounts, and stale service credentials create escalation routes

The danger is not one privileged account. It is the overlap.

If a workstation admin can also read file shares, if a service account can also log on interactively, or if a helpdesk role can reset the wrong passwords, then the attacker only needs to find the overlap once.

Common failure modes:

How to audit for tiering problems, local admin drift, and credential reuse

Start with the obvious group membership checks:

Get-LocalGroupMember -Group "Administrators"

On domain controllers and servers, review the equivalent local admin sources, GPOs, and restricted groups. If the same domain group is sprinkled across multiple tiers, separation is already gone.

For Active Directory privileges, inspect the high-impact groups:

Get-ADGroupMember "Domain Admins"
Get-ADGroupMember "Enterprise Admins"
Get-ADGroupMember "Administrators"

Example output that deserves a follow-up:

Name                 ObjectClass
----                 -----------
svc-backup            user
helpdesk-jane         user
workstation-admins    group

That is not automatically wrong, but it is the kind of list that often hides “temporary” access that never got removed.

I would also review service accounts for three things:

1. interactive logon rights
2. password rotation
3. whether the account is privileged far beyond its job

If the same account can authenticate to multiple tiers and a human can log into it, treat it as a lateral-movement candidate.

Lateral movement is where the incident stops being a single host problem

The Windows services, remote execution paths, and file shares defenders should map first

Once the attacker has one foothold and some privileges, the usual paths are not subtle:

• SMB for shares and remote file staging
• WinRM for remote command execution
• WMI for remote administration
• PsExec-style service creation
• RDP to jump from workstation to server
• scheduled tasks and service creation for persistence or execution

The real question is not whether these tools exist. They do. The question is whether one compromised workstation can reach everything that matters.

A defensive reachability sweep from a standard admin workstation:

$targets = @("server1","server2","dc1")
$ports = 3389,445,135,5985
foreach ($t in $targets) {
  foreach ($p in $ports) {
    [pscustomobject]@{
      Target = $t
      Port = $p
      Open = (Test-NetConnection $t -Port $p -InformationLevel Quiet)
    }
  }
}

If a low-trust endpoint can reach SMB, WinRM, and RDP on sensitive hosts, lateral movement is too cheap.

What segmentation, firewall rules, and domain logging should block or expose

The minimum posture is:

• workstation-to-server access is denied by default
• only management subnets can reach admin protocols
• servers cannot freely talk to every other server
• domain controllers are isolated from ordinary user traffic
• sensitive shares are not broadly readable from user VLANs

You should also log the remote-execution paths that matter:

• service creation events
• new scheduled tasks
• remote logons
• share access
• PowerShell operational logs where feasible

If you only alert on malware hashes, you are already late.

Reproducible checks for proving whether one compromised workstation can reach the rest of the domain

I like to reduce this to one question: from a user workstation, what can I touch that I should not be able to touch?

A quick practical test:

$hosts = @("fileserver01","appserver01","dc01")
foreach ($h in $hosts) {
  [pscustomobject]@{
    Host = $h
    SMB  = Test-NetConnection $h -Port 445 -InformationLevel Quiet
    RDP  = Test-NetConnection $h -Port 3389 -InformationLevel Quiet
    WINRM = Test-NetConnection $h -Port 5985 -InformationLevel Quiet
  }
}

If the answer is “all of them,” then segmentation is mostly documentation.

Domain-wide encryption is a blast-radius problem, not just a malware problem

Why attackers aim for domain-admin-level control before they deploy encryption

Encryption at scale usually comes after the attacker has enough authority to push software, kill backups, disable defenses, or stage payloads across many machines.

That is why domain-admin-level control matters so much. It turns one foothold into synchronized damage.

This is the part teams sometimes miss: the encryption binary is not the main event. The blast radius is.

If a threat actor has:

• broad admin rights
• reachable endpoints
• weak segmentation
• and backup control

then the outcome is not “one encrypted server.” It is often a full outage.

How backup design, offline copies, and recovery permissions decide whether encryption becomes a full outage

Backup strategy decides whether the incident is annoying or existential.

I would verify:

• backups are immutable or otherwise resistant to tampering
• at least one copy is offline or isolated
• backup admin credentials are separate from domain admin
• backup systems are not reachable from ordinary workstation subnets
• restore permissions are tested before an incident

If the same domain admin path can both destroy production and delete backups, your recovery story is ceremonial.

What to verify in restore drills so the backup story is real, not ceremonial

A good restore drill answers hard questions:

1. Can we restore a critical system without using the everyday domain admin account?
2. Can we rebuild identity services if Active Directory is damaged?
3. Are restore credentials stored separately from production credentials?
4. Do we know the order of recovery for domain controllers, PKI, backup infra, and business apps?
5. Have we tested the restore in a way that proves data consistency, not just file copy success?

If your last test ended at “the backup job ran successfully,” that is not a restore drill.

A practical audit checklist for a modern stack

External exposure review: internet-facing RDP, VPN, and jump-host paths

• inventory every host that accepts remote access
• confirm whether RDP is exposed directly or only through hardened entry points
• require MFA on VPN and administrative access
• restrict admin access to named bastions and trusted devices
• remove stale firewall rules and forgotten port forwards

Active Directory review: privilege boundaries, service accounts, and logging coverage

• enumerate privileged groups and compare them to actual job roles
• remove shared administrative credentials
• separate workstation, server, and domain admin tiers
• review service account scope, rotation, and interactive logon rights
• ensure domain controller logging is centrally collected

Detection review: alerts for suspicious logons, remote execution, and mass file changes

• alert on bursts of failed logons against privileged accounts
• alert on logon patterns from unusual source hosts or geographies
• monitor service creation, scheduled tasks, and remote management use
• watch for unusually broad file modification on shares
• test whether these alerts reach a human in time

Recovery review: backup immutability, test restores, and domain rebuild assumptions

• confirm at least one backup copy cannot be altered from domain-admin context
• test restores of identity services, not just file shares
• document the recovery order for core infrastructure
• separate backup credentials from production admin credentials
• rehearse the rebuild path before you need it

The conclusion I would defend in a security review

If an attacker can move from exposed remote access to domain encryption, the architecture has already failed

That is the assessment I would put in front of leadership.

The sentence is the story. The control failure is the lesson. A Conti-style actor does not need exotic capability if your stack still gives them internet-reachable remote access, oversized identities, weak internal boundaries, and backup systems that trust the same domain.

The fixes belong in access design, identity hardening, segmentation, and recovery engineering

If you want to reduce ransomware impact, do not start with the payload. Start with the chain:

• stop exposing remote access directly
• harden identities and remove privilege sprawl
• make lateral movement expensive
• make backup destruction difficult
• prove recovery with drills, not hope

That is the audit I would run after reading the sentencing report. Not because it is fashionable, but because it is still where real environments fail.