Protecting Against Ransomware: Measures for Servers and Workstations

What ransomware actually does and why it matters

Ransomware is malware that quickly makes data unavailable: files get new extensions, folders stop opening, and a ransom note appears on the screen. For a business this almost always means downtime, missed deadlines and stressful decisions. So protection is not just "an antivirus just in case", but risk management.

An attack typically starts from simple entry points: a phishing email with an attachment, a stolen remote-access password (for example RDP), exploitation of a vulnerability in a public service, or an infected USB stick. The attacker then persists in the network, escalates privileges and goes for the most damaging targets.

Both workstations and servers are affected because they are connected by shared accounts, network drives and administrative rights. An infected employee laptop can start encrypting a shared file resource within minutes, then hit servers hosting databases, virtual disks or archives.

Common targets are shared folders and network drives, databases (for example 1C and industry systems), VM storage, sales, legal and HR documents. A particular risk is backups if they are available over the network like an ordinary share.

Prepare for three things: forced process stoppage, pressure via ransom demands, and a lengthy recovery. Even if data can be restored, trust, reporting and reputation questions remain. The earlier you picture this scenario, the easier it is to choose measures that truly limit damage.

Where to start: a quick audit and priorities for 2 weeks

To make measures effective, start not by buying new software but by understanding what you have and what is critical for operations. The goal for the first two weeks is to remove the most common causes of "mass encryption" and enforce basic rules.

Gather a short inventory: servers and workstations, their roles (file server, 1C, mail, domain controller, terminal server), and what the company needs "the next day" to continue working. A simple list with system owners and contacts is enough.

Then make a "data map": where important files live (shared folders, network drives, cloud, local directories), who accesses them and how. Often you discover one shared resource is writable by "everyone" — that becomes the point of greatest damage.

For the next two weeks focus on clear things:

• Unified OS and software update policy. Users should not install "anything they want".
• Minimal segmentation: users, servers, admin workstations and backups should have different accesses and, if possible, different networks.
• Accounts and permissions: remove shared accounts and overly broad permissions at least on critical resources.
• Basic logging: log logins, permission changes and bulk file operations.
• Owners: who updates, who reviews logs, who decides to isolate a host.

Practical example: accounting uses a shared disk and the IT admin accesses it with an "all-powerful" account. If the accountant's PC is infected, the malware gets maximum access. Two weeks is usually enough to close this class of risk: narrow permissions, separate admin and user tasks, and set updates across devices including servers and standardized workstations.

Server hardening: the minimal set that works

Servers interest ransomware not by themselves but as a springboard: through them an attacker can reach shared folders, backups, credentials and the domain. The basic principle is simple: keep only what is needed for operations and close everything else.

Start by removing the unnecessary: disable unused services and roles, close unused ports on the host and firewall, eliminate guest shares and anonymous access. Quick wins often come from dropping old protocols (for example SMBv1) and blocking direct access to admin interfaces from user subnets.

Next — scheduled updates. Not "sometime later", but fixed update windows for OS and key software (remote access, web services, VPN, management agents). Ransomware regularly exploits long-patched vulnerabilities simply because the patches were not applied.

The third area is protecting the protection tools. Enable tamper protection in antivirus/EDR, restrict rights to stop security services and configure alerts on attempts to disable them.

If you need a prioritized checklist that usually pays off first, keep this minimum:

• Restrict scripts: strict policies for PowerShell/WSH, block execution from temp folders.
• Reduce macro risk: block macros from the internet, allow only signed macros where really needed.
• Strengthen passwords and login: length requirements, account lockout after repeated failures.
• Protect remote access: MFA for admins, restrict RDP by addresses/groups, use separate admin accounts.
• Remove shared privileges: service accounts get only the permissions they need.

Example: a file server with a shared folder "Exchange". If guest access and wide write permissions exist, one infected PC will encrypt everything quickly. If guest shares are removed, permissions separated and script execution limited, the attack often stops at a single workstation.

Workstation hardening: what actually reduces infection risk

Workstations are often the entry point: an email attachment, an invoice in an archive, a fake login page, or accidental installation of a "codec". On PCs the most important are basic restrictions that prevent malware from persisting and running.

Rule one: a regular user should not be a local administrator. If an employee can install drivers and change system settings, the ransomware gets the same rights. Use a separate admin account or temporary privilege elevation for rare tasks.

Step two — restrict software installation. A common approach: allow a standard set of applications and signed updates only; everything else requires approval. This greatly reduces accidental installs that lead to infection.

Check email and office usage. Gateways are macros and attachments. A useful minimum:

• Macros disabled by default. Execution only for trusted documents.
• Attachments from the internet open in protected mode; archives and executables are blocked by rules.
• Browser and office suite update automatically.
• Laptops have full-disk encryption and login protected by a strong password and MFA where possible.
• Accounts are subject to lockout policies for suspicious login attempts or brute-force.

Simple example: an employee opens an attachment, malware attempts to install a "service" and spread. Without admin rights and with execution blocked for unknown files, the attack often stops on that PC and cannot reach shared folders.

Separation of privileges: how to stop ransomware from spreading

Ransomware usually starts with regular user rights and then tries to expand access: steal passwords, reach shared folders, touch servers. Separation of privileges is one of the most powerful measures: it won't prevent infection, but it dramatically reduces the scale of damage.

The principle is simple: each person should have access only to what they need daily. If an accountant needs access to reports once a month, that’s not a reason to give them full access to the file store.

Admins need a special approach. Use two accounts: a normal one (mail, browser, documents) and an admin one (administration only). Do not use the admin account for regular desktop tasks. A common chain is: an admin signs into an infected PC and malware then gets keys to the entire domain.

Clean up file and share permissions: remove Everyone and broad groups, keep clear roles (read, modify) and owners. Pre-identify critical folders where write is allowed for a small group only.

Step-by-step start:

• Introduce separate admin accounts and forbid their use for daily work.
• Block interactive admin logins on workstations where not needed.
• Review shared folder permissions and remove wide permissions.
• Limit local admin rights on PCs.
• Enable MFA where possible: VPN, email, admin panels.

If you have a systems integrator or internal security team, document rules in a short procedure and test them on a pilot group before full rollout.

Network and remote access: simple isolation without complexity

Even if ransomware lands on one PC, it still has to reach servers, shares and backups. Network design and remote access often provide the shortest path, so basic isolation brings quick benefits.

Start with minimal separation: user workstations and guest Wi‑Fi in one network, servers and admin services in another. Allow only what is necessary between them (for example access to the file server on specific ports), not "everything".

For administration create a single secure entry: a jump server or a dedicated admin contour. The idea is that admins do not access servers directly from ordinary workstations. That way, even if a user PC is compromised, malware has no direct route to critical infrastructure.

Remote access is often abused via RDP. Keep it under control:

• Allow RDP only through VPN and only for needed groups.
• Use IP whitelists where realistic.
• Enable auditing of logins and failed attempts.
• Deny access "from any computer" to management servers.
• Disable RDP where it is not needed.

Protect the backup network: there should be no route from the user zone into backup infrastructure. The backup server should "pull" data rather than accept connections from everywhere.

If you have racks with S200 Series in the server room and workstations on L200, check that management interfaces and storage are reachable only from the admin network. This small setting often decides whether an incident becomes a catastrophe.

Backup isolation: how to ensure you can restore

Ransomware almost always tries to reach backups: delete, encrypt or change retention policies. The rule is that backups must live separately and not be accessible with the same credentials as regular files.

A good anchor is the 3-2-1 rule. The point is not the numbers but ensuring that an attack on the domain or file server does not destroy all copies at once:

• At least three copies of data: the production copy and two backups.
• Different storage types (for example disk plus object storage or tape).
• One copy offline or at least outside the domain and not accessible with normal credentials.

Immutability greatly strengthens protection: modes that prevent deletion or overwriting until retention expires. This can be WORM, an immutable bucket, or protected snapshots with strict retention. Even with access to the server, an attacker will find it much harder to "clean up" traces.

Use separate accounts for backup systems. The backup solution should use its own service user without domain admin rights, and admins should not access the backup console with the same AD accounts they use elsewhere.

Restore verification matters more than a "backup successful" report. Minimum regular checks:

• Weekly: selective file restores to a test folder.
• Monthly: restore a VM or server into an isolated environment.
• Quarterly: full critical-service recovery test from scratch.

Don't forget items often missed: System State/AD, hypervisor configs, network device rules and configs. In a crisis these often reduce downtime from days to hours.

Logs and monitoring: what to watch to spot an attack earlier

Even good controls won't help if you only hear about an attack in the morning from accounting. Logs and simple alerts give you a chance to catch the first steps: password guessing, suspicious processes, bulk file changes.

Start auditing where it is usually "quiet": logins, permission changes and work on shared folders. On file servers and domain controllers watch events that show sharp changes and atypical activity.

Useful minimum monitoring set:

• Failed and unusual logins (night time, new devices, odd locations).
• Addition of users to admin groups and permission changes on network resources.
• Disabling of antivirus/EDR or update services.
• Mass renames and overwrites on shares.
• Execution of unknown binaries from temp folders and user profiles.

Alerts should go to named people, not a general mailbox. Define who receives notifications, who decides on isolation of a PC or server, and target response times (for example 15 minutes in business hours and 30 minutes at night on-call).

Protect the logs themselves. A compromise with admin rights often includes attempts to delete traces. Give view rights to those who need them but restrict deletion and modification. A good practice is forwarding events to a separate log-collection server that workstations and normal admins cannot clear.

If suspicion is confirmed, know in advance what to collect for investigation:

• System and security logs (Windows/Linux) for the last 24–72 hours.
• Antivirus/EDR logs and detection details.
• List of recently installed programs and updates.
• Memory snapshot or disk image of the critical machine (if possible).
• List of affected network shares and accounts under whose identity the encryption ran.

Example: one PC starts rapidly changing files on a department share. If you have an alert for spikes in operations and new file extensions, you can disconnect that PC and temporarily close access to the resource before the whole drive is compromised.

Response scenario: step-by-step plan for the first 4 hours

The goal of the first hours is to stop encryption, preserve evidence and keep restoration options open. The plan below suits both a server and a workstation showing strange extensions, mass access errors or a ransom note.

First 30 minutes: stop the spread

Act fast but carefully. When in doubt, isolate more rather than less.

• Immediately disconnect the suspicious machine from the network: unplug the cable or disable Wi‑Fi. Do not power off unless there is a risk of damage.
• Stop access to shared resources: temporarily disable shared folders on the file server and unmap network drives in affected departments.
• Lock the account used by the infection and reset its password. If it’s an admin account, treat the incident as critical.
• Suspend remote access that could have been an entry: pause RDP/VPN for suspicious users and external addresses.

Record basic facts: which hosts are affected, time of first symptoms, and which folders were hit.

30–240 minutes: evidence, backups, recovery

Collect minimal evidence before any cleanup: running processes and autostarts, active connections, recent log events. If possible, take a disk image or VM snapshot. This will help determine how the attacker got in and prevent repeat mistakes.

Simultaneously check backups. Ensure they are not encrypted or deleted: open a few files from backup and verify dates. Choose a restore point prior to the first signs of activity.

Restore by priority: domain services first, critical file resources and departmental services next, then workstations. Before reconnecting to the network, change passwords, review access policies and harden program execution controls. Trying to "quickly restore everything" often leads to re-encryption.

After the incident, close the cause: apply patches, tighten remote access rules, separate privileges and isolate backups. If you don’t, reinfection often happens within days.

Real-life example: how one PC can encrypt a shared drive and what helps

Scenario: an employee opens an email attachment and ransomware runs on their PC. It first encrypts local files, then moves to network drives. If the user had a mapped shared resource (for example "Department"), the malware starts renaming and changing documents on the share using that user’s ordinary rights.

Quick, clear actions reduce damage:

• Immediately disconnect the PC from the network (cable or Wi‑Fi).
• Lock the user account and terminate their sessions on the file server.
• Temporarily close the shared resource for the group if mass encryption is visible.
• Record basic artifacts: PC name, logins, time of first changes, list of affected folders.
• Notify the responsible people and follow the predefined response plan.

Assess the scope quickly. Often the malware operated with ordinary user rights and damaged exactly what that user could write to. So it’s critical to determine whether only one share was affected or there are signs of compromise via RDP and escalated accounts.

Recovery starts with critical folders (finance, contracts) but only after the source is isolated and no further encryption is occurring. Then restore access and closely monitor changes.

Two things usually save you: separation of privileges (no write access to other departments or system directories) and backup isolation (backup copies not mounted as regular disks and unreachable from user workstations).

The main idea is simple: one infected PC must not be able to "take down" the entire file server just because of a single set of permissions.

Common mistakes that let ransomware finish off infrastructure

Ransomware rarely wins because of technical sophistication. It’s usually habits and convenient but unsafe choices that help it.

Typical sequence: an employee opens an attachment, malware runs and immediately gets access to shared folders. If permissions were given "just in case", not only their folder gets encrypted but also departmental and shared resources.

Mistakes that most often turn one infected PC into a department- or company-wide outage:

• Overly broad permissions on file servers and shares (everyone has write, inheritance unchecked).
• One admin account "for everything" used to log into user PCs. Malware then gains privileges via an active session.
• Backups located in the same network and accessible with the same credentials as working data.
• Delayed updates due to fear of downtime, leaving known vulnerabilities open.
• Backups exist but recovery was never tested; on incident day copies turn out incomplete or unreadable.

A useful rule: if an attacker logged in as a normal user, they must not automatically get access to admin tools, mass write on shares or deletion/encryption of backups.

Short 30-minute checklist: quickly assess readiness

A full audit takes more than half an hour, but a quick check shows the most painful gaps and what to close first.

The point is not whether something is "configured", but whether you can prove it right now.

• Backups: is there at least one backup separated from the domain and workstations (not just a network disk), and was a recovery test done in the last 30 days?
• Admin accounts: where are admin accounts used? Are there separate admin accounts and a rule "admins don’t use mail or browsers"?
• Remote access: is RDP exposed directly to the internet? If in doubt, treat it as a risk. Note who connects remotely and by what method.
• Updates: are critical servers and main workstations patched with recent updates (at least cumulative OS and office updates)?
• Logs and alerts: are basic logs enabled on servers and is there at least one meaningful alert (for example multiple failed logins or mass changes on a shared resource)?

Finish by answering two questions: who decides on isolation (disconnect PC, close shared folders, stop services) and what exactly is done in the first 4 hours. If answers are vague, assign specific people and write down the sequence. This saves hours when things are happening under pressure.

Next steps: a one-month work plan and task owners

To avoid measures remaining a set of ad-hoc tweaks, document a one-month plan: what to do, who owns it and what the expected outcome is. Start with 10–15 highest-priority tasks and agree them with business-service owners.

4-week plan

• Week 1: collect the current picture (critical servers, shared folders, remote access, backup locations), assign task owners and readiness criteria.
• Week 2: pilot on one segment (access rights, segmentation, backup isolation, basic logs) and verify nothing breaks.
• Week 3: prepare standard policies for servers and endpoints and deploy to 30–50% of the estate.
• Week 4: run a short response drill (1 hour) and roll out to the remaining systems.

A simple validation: take a typical scenario (PC infection and attempt to encrypt a shared disk) and walk through it step by step. You’ll immediately see missing responsible contacts, how long it takes to find logs and who can disable access to a resource.

Who should own tasks

• Information Security owner: priorities, risk control, approval of exceptions.
• System administrators: hardening, updates, policies, accounts.
• Network administrator: segmentation, firewall rules, remote access.
• Backup owner: isolation, recovery checks, RPO/RTO accounting.
• Service owner (business): agrees maintenance windows and verifies service availability.

If you lack staff or need design of a target scheme (servers, segmentation, recovery), involve a systems integrator. For example, GSE.kz as a server vendor and systems integrator can help design infrastructure, configure processes and provide 24/7 technical support through a service network.