What the Murray County Ransomware Breach Teaches About Backup Isolation and Segmentation

Why the reported Murray County payment is a useful technical case study

The public report says Murray County paid $200,000 to ransomware attackers after a cyber breach. The number is important, but not because it is the most interesting technical detail. The payment is the visible outcome. The real story is usually earlier in the chain: how the attackers got in, how far they moved, whether they found backups, and whether the county could restore services before the extortion window closed.

I am treating this as a backup isolation and segmentation case study, not as a postmortem on one county’s internal network. The public details are limited, so the safest way to look at it is to ask the questions that decide whether a ransom becomes “the cheapest option available”:

• Could the attackers encrypt production and backup systems from the same foothold?
• Could they delete restore points or make them untrustworthy?
• Could the county rebuild identity and core services without first trusting the compromised directory?
• Did the network let one stolen credential reach too much?

Those questions are the difference between an incident that hurts and an incident that turns into a budget line item.

Treat the $200K payment as an outcome, not the core failure

People like to argue about whether paying is “right” or “wrong,” but technically the payment comes after a failure in resilience. A ransom is what happens when the defender’s recovery path is weaker than the attacker’s leverage.

In practical terms, that leverage comes from three things:

1. Data reachability — can the attacker access the systems that matter?
2. Restore trust — can you trust that your backups are intact?
3. Restore speed — can you get essential services back before county operations stall?

If a county can restore payroll, records, email, public-facing services, and identity quickly enough, the ransom demand loses force. If backup storage, backup consoles, and admin paths live inside the same trust zone as production, the attacker can often remove that option before anyone has time to respond.

The real questions are blast radius, restore speed, and extortion leverage

I usually reduce ransomware incidents to a simple map:

A ransom payment often means the defender lost on at least two of those at once. If identity is compromised and backups are reachable from the same admin plane, then “offline” starts to mean “not immediately visible,” which is not the same thing as safe.

What ransomware usually does after initial access

The malware itself is rarely the whole problem. The serious damage usually happens after initial access, when the attacker shifts from foothold to preparation.

In a typical enterprise or county network, the sequence looks like this:

1. Get initial access through phishing, exposed remote access, stolen credentials, or a vulnerable service.
2. Expand privileges.
3. Enumerate hosts, shares, backup tooling, and identity systems.
4. Disable defenses and delete or corrupt backup history if possible.
5. Encrypt data or exfiltrate first, then encrypt.
6. Use the downtime to force negotiation.

The exact tools vary, but the shape is familiar.

Credential theft, lateral movement, and backup discovery

Once an attacker has one machine, they usually try to answer three questions quickly:

• Where are the domain admins?
• Where are the file servers?
• Where are the backups?

Backup systems are high-value because they control the one thing defenders need most after encryption: clean restores. If backup servers share credentials with the main domain, or if the backup console is reachable from normal admin workstations, then the attacker does not need a special exploit. They just need the same credentials that already have access.

That is why lateral movement matters more than the initial malware family. A commodity loader becomes a serious incident once it can harvest tokens, query Active Directory, and reach a backup appliance.

Why flat networks make recovery harder than the malware itself

A flat network turns one compromise into a browsing session.

If every server can talk to every other server, and every admin can reach every management interface, then an attacker can move from endpoint to file server to backup server with very little friction. That is not just a containment problem. It is a recovery problem too.

Flat networks create three bad conditions:

• Backup discovery is easy because the systems are visible from the same layer.
• Credential reuse is effective because the same identity can reach many targets.
• Recovery ordering gets messy because the systems needed to rebuild one another are all contaminated at the same time.

In that environment, the malware does not need to be clever. The architecture does the work for it.

Backup isolation: what it actually means in practice

People say “isolate backups” a lot, but the phrase gets used loosely. In practice, isolation should mean the attacker cannot use production compromise to destroy the backup path.

Separate identity, separate network path, separate admin surface

A backup environment should be separated in three ways:

• Identity separation: backup admins should not use normal domain admin accounts.
• Network separation: production systems should not have broad reach to backup storage or consoles.
• Admin surface separation: the backup management plane should sit behind hardened access, not be exposed through everyday endpoints.

If any one of those is missing, the rest are weaker than they look.

For example, a backup server on a different VLAN is not very isolated if it is still domain-joined and managed by the same enterprise admin accounts used everywhere else. The network looks separate, but the trust chain is not.

Immutable storage, object lock, and air-gapped copies

There are three useful patterns here, and they solve slightly different problems:

• Immutable storage prevents modification or deletion of backup objects for a retention period.
• Object lock / WORM retention gives storage-level enforcement so even privileged users cannot casually overwrite.
• Air-gapped copies keep at least one backup copy unreachable from the compromised environment.

These controls work best together. Immutable storage is useful, but if an attacker can log into the console and disable policy before the lock takes effect, you still have a timing problem. Air gaps are useful too, but if the only way to reach them is through the same identity plane, you may still have a control-plane problem.

When “offline” backups still fail because they are reachable from domain admin

This is the trap I see most often. A team says the backups are offline, but the backup appliance is still AD-integrated, the console is accessible from normal admin workstations, and a domain admin account can delete retention policies.

That is not offline. That is just inconvenient.

A useful test is simple: if a compromised domain admin account can destroy backup history, then the backups are not isolated enough. You may still have copies, but you do not have credible recovery assurance.

Segmentation as the containment layer before backup ever matters

Backup isolation is the last line of defense. Segmentation is what keeps the incident from reaching that line in the first place.

User VLANs, server VLANs, backup VLANs, and management VLANs

A county-style environment usually ends up with a few major zones:

• user workstations
• application and file servers
• identity services
• backup infrastructure
• management/jump hosts
• public-facing services

The important part is not the number of VLANs. The important part is the trust model between them.

A practical layout looks like this:

The goal is to make “normal” traffic boring and predictable. If everything can talk to everything, the network becomes a privilege escalation path.

Restricting east-west traffic and backup server reachability

Ransomware loves east-west movement. If one workstation can scan the subnet, hit SMB on dozens of servers, and authenticate to the backup console, then the attacker does not need persistence for long. They just need enough reach.

Good segmentation reduces that reach:

• Workstations should not talk directly to backup repositories.
• Servers should only talk to the specific backup proxy or agent they need.
• Backup consoles should accept admin access only from hardened management hosts.
• Management hosts should not browse email, websites, or general workloads.

A lot of organizations get the perimeter right and the inside wrong. Ransomware usually enters through something inside the perimeter.

Why segmentation is about limiting credential reuse, not just packets

Packet filtering alone does not solve the problem. If the same admin credential can be used from any machine, segmentation turns into a speed bump.

The real goal is to make stolen credentials less useful:

• require jump hosts for admin access
• use separate credentials for backup administration
• use just-in-time elevation where possible
• enforce MFA on management paths
• block direct workstation-to-management access

When credentials are portable across zones, segmentation weakens. When credentials are scoped to specific zones and devices, segmentation starts to do real work.

A practical county-style environment model

County IT tends to have a recognizable shape. There are public records systems, finance tools, file shares, identity services, end-user fleets, and a few overloaded admins trying to keep everything running.

Common assets: file servers, finance systems, public records, endpoint fleets, and identity services

A realistic set of assets might include:

• Windows endpoints for staff
• file servers for shared documents
• finance and payroll systems
• public records or case management systems
• domain controllers
• backup software and storage
• remote access gateways
• printing and line-of-business apps

Each of these has different recovery priority and different trust requirements. Not all of them should be able to talk to backups, and not all of them need to talk to identity systems in the same way.

Which systems should be able to talk to backups, and which should never need to

A good rule is to ask: “What is the minimum path required for backup and restore?”

Usually:

• production servers may need to send backup data to a proxy or repository
• backup proxies may need to read from servers
• restore operators may need to pull from the backup console through a management host

Usually not:

• user endpoints directly reaching backup repositories
• file servers browsing backup administration interfaces
• domain users accessing backup retention controls
• internet-facing services touching the backup plane at all

Here is the control question I would use in review: if the finance file server is compromised, can it enumerate the backup repository? If yes, the trust boundary is too wide.

Mapping trust boundaries before writing firewall rules

People often write firewall rules after the fact, based on what already works. That is backwards.

Start with trust boundaries:

• Which systems are untrusted?
• Which systems are sensitive?
• Which systems are recovery-critical?
• Which systems are allowed to initiate admin actions?

Then write traffic rules based on that map.

If you do this properly, the firewall policy is not a pile of exceptions. It is an expression of the architecture.

How to design an isolated backup architecture that survives compromise

If I had to reduce this to a design checklist, I would start here.

Separate backup credentials from domain credentials

This is non-negotiable.

Backup administrators should not log in with normal domain admin accounts. Backup services should not authenticate with reusable high-privilege credentials that also unlock other infrastructure.

Prefer:

• separate admin identities
• MFA-protected privileged access
• time-limited elevation
• dedicated service accounts with narrow scope
• rotation and vaulting for secrets

The goal is not just stronger authentication. The goal is to stop one credential from becoming the key to every door.

Use write-once or immutable retention for critical restore points

At least some restore points should be protected from deletion and modification, even by privileged users in the production environment.

That gives you time. Time is the one thing ransomware tries to take away.

Use immutable retention for:

• recent full backups
• system-state backups for identity services
• quarterly or monthly archival points
• known-good restore anchors before major changes

That last piece matters. If all your backups are recent but all recent backups were created after the compromise, you have a clean encryption copy and nothing else.

Limit backup console access to a hardened admin path

Backup consoles are not general-purpose admin web apps. They should be treated like crown-jewel interfaces.

Good practice:

• access only from hardened jump hosts
• restrict by IP, device, and user
• require MFA
• log every privileged action
• alert on retention changes, repo deletion, and mass restore job creation

The console should not be something an operator casually opens from a laptop on the office network.

Test restore without relying on the production directory service

This is the one people skip until they need it.

If your restore process depends on the same domain controllers that were compromised, the same DNS that may have been altered, or the same identity path that the attacker touched, then the restore is partly hypothetical.

A better drill is:

1. restore to an isolated network
2. boot clean identity services first
3. validate authentication independently
4. restore one application at a time
5. verify data integrity before reconnecting

A restore that requires a healthy production directory service is not really a recovery plan. It is a dependency loop.

Recovery mechanics: what a fast restore actually requires

Fast recovery is not just “we have backups.” It is a choreography problem.

Prioritize identity, core network services, and restoration order

If identity is down, everything feels broken. If DNS is broken, nothing seems reachable. If virtualization management is compromised, a lot of servers are hard to trust.

A sensible order is usually:

1. management and out-of-band access
2. core network services such as DNS and DHCP, if applicable
3. identity services from known-good sources
4. backup management in a clean admin zone
5. critical line-of-business servers
6. lower-priority shared services

The exact sequence depends on the environment, but the rule stays the same: rebuild the control plane before you reconnect the payload.

Validate data integrity before reconnecting restored systems

A restored VM or file share is not automatically safe. It may contain malicious scripts, poisoned configs, or corrupted data.

Before reconnecting:

• verify hashes or backup integrity reports
• compare restored system configuration to a known baseline
• review startup items, scheduled tasks, and service accounts
• check for unexpected admin group membership
• validate business data with the owners, not just the IT team

Recovery is not done when the server boots. Recovery is done when the system can rejoin production without reinfection.

Rebuild vs. restore decisions for compromised hosts

Not every host should be restored in place.

Rebuild when:

• the host is part of identity or management infrastructure and may be deeply trusted
• the compromise path is unknown
• local admin or system-level access was confirmed
• the machine has sensitive agents or credentials cached

Restore when:

• the asset is low-risk and the image is known clean
• the application state matters more than the host identity
• the environment is isolated and validated

The important thing is to avoid emotional restoration. “Put it back the way it was” is not a recovery strategy.

Verification steps you can run in a safe environment

These checks are defensive and scoped. They are the kind of things I would run in a lab, staging network, or an approved internal assessment.

Check whether backup servers can be reached from normal user networks

From a user workstation, verify whether backup consoles or repositories are even visible. If they are, ask why.

Useful checks in a controlled environment:

## From a standard user network segment, test basic reachability
ping <backup-host>   # if ICMP is allowed in your environment
nc -vz <backup-host> 443
nc -vz <backup-host> 9393

You are not trying to break anything. You are checking whether the production user zone has any business seeing the backup zone at all.

Check whether one stolen admin account can delete backup history

This is a critical control test.

In a lab or maintenance window, use a limited admin role and verify:

• can it delete repositories?
• can it reduce retention?
• can it disable immutability?
• can it approve restore deletions?
• can it alter backup job history?

If the answer is yes to any of those with a routine admin account, the backup plane is too easy to subvert.

Check whether restores depend on the same domain that was breached

This is one of the most important questions you can ask.

Attempt a restore path in isolation and verify:

• does the backup console need the production domain to authenticate?
• does the restore target need production AD before boot?
• do backup agents require domain trust to re-register?
• does DNS for the recovery path come from the compromised network?

If the restore path cannot stand on its own for the first few hours, the architecture is brittle.

Check whether immutable backups can be altered through the console

Immutability is only useful if privileged users cannot casually undo it.

Test:

• retention lock enforcement
• console controls for policy changes
• role separation for storage admins vs. backup operators
• audit logs for attempted deletion and policy edits

If immutability can be disabled by the same accounts that run daily operations, the attacker only needs to win one credential battle.

Common failure modes that make ransom payments more likely

This is where most real environments fail, including ones that look mature on paper.

Backups stored on the same authentication plane as production

If your backup vault depends on the same directory, the same SSO, and the same admin group as production, then compromise of one plane gives the attacker leverage over the other.

That does not mean you can never integrate with enterprise identity. It means the backup path needs a different trust model, tighter privileges, and a recovery plan that still works when production identity is suspect.

Shared admin credentials across servers, endpoints, and backup tooling

Shared credentials are a gift to attackers.

If the same password or privileged account can:

• log into servers
• manage endpoints
• access backup consoles
• administer virtualization
• modify storage retention

then the environment behaves like one big machine from the attacker’s point of view.

No restore rehearsal, so recovery time is only theoretical

Plenty of organizations can say they have backups. Fewer can prove they can restore a domain controller, a file server, and a finance database under pressure.

If you have never rehearsed the sequence, your RTO is fiction.

Backups that exist but cannot be restored at usable speed

A backup that takes 36 hours to recover is not the same as a backup that can restore critical services in 4 hours. The attacker does not need to erase your backups if the delay is enough to force a payment.

Speed is part of the security property.

Hardening checklist for backup isolation and segmentation

Minimal network paths, minimal trust, minimal privileges

Start with these rules:

• no direct workstation access to backup consoles
• no broad server-to-backup network access
• no shared admin credentials across production and backup
• no domain admin requirement for routine backup operations
• no Internet exposure for management interfaces

The architecture should make the attack path awkward.

Logging, alerting, and restore verification as first-class controls

You want alerts for:

• backup retention changes
• mass deletion attempts
• repository reconfiguration
• new admin creation
• failed login bursts to backup consoles
• unusual restore jobs or job cancellations

You also want scheduled restore verification. A backup that is never tested is a story, not a control.

Ransomware-specific detection on backup deletion, mass encryption, and admin abuse

Detection should not stop at endpoint antivirus.

Good signals include:

• a backup operator account logging in from a new device
• admin activity outside normal maintenance windows
• rapid file renames or encryption-like write patterns
• disabled services followed by repository activity
• attempts to enumerate backup shares from user segments

The key is to correlate identity, network, and storage events. Ransomware leaves a pattern when it is trying to reach the backup plane.

What this incident teaches about extortion leverage

Isolation reduces the attacker’s bargaining power even when prevention fails

The public Murray County payment is a reminder that once the attacker has enough leverage, the economics start to favor the ransom. Isolation changes those economics.

If the attacker cannot reach backups easily, cannot delete restore points, and cannot rely on one credential to control the recovery path, they have less leverage. They may still disrupt systems, but the defender has more credible alternatives.

That is the real defensive value of isolation: it makes extortion less persuasive.

Segmentation buys time, and time is what recovery needs

Segmentation does not magically stop all ransomware. What it does is slow the spread and protect the systems you need to rebuild.

That extra time matters because recovery is a sequence, not a switch:

• contain the spread
• preserve evidence
• clean identity
• restore infrastructure
• validate data
• reconnect systems carefully

Every minute segmentation buys you is a minute the attacker does not get to turn into pressure.

Conclusion: the payment is expensive, but the architecture lesson is cheaper

A $200,000 ransom is a painful number, but the more expensive lesson is architectural. If backup systems, admin paths, and production identity all sit in the same trust plane, the attacker can often win without much sophistication.

The practical defense is not “have backups.” It is:

• isolate backup identity
• segment the network so production cannot casually reach recovery systems
• protect restore points with immutability or write-once retention
• rehearse recovery from a compromised-directory scenario
• verify that one stolen admin account cannot destroy your escape hatch

I would rather see a county spend effort on those controls than spend six figures on a decision made under pressure. The payment is the visible event. The real security work is everything that should have made payment unnecessary.