← Practice · October 22, 2026

Recovering a Server After Ransomware: Getting the Office Running Over a Weekend

How we rebuilt Windows Server, 1C and the office network, closed external RDP access and got employees back to work after an attack.

12 min readserver

Overnight from Friday to Saturday, the company effectively lost its information system. The server was encrypted, the production databases were inaccessible, and so were the archives on the backup drive. The company operates every day: putting work on hold and waiting for a decryptor was not an option. By Monday, employees were working on a new server.

We split the recovery into two tasks: restoring the working infrastructure and reconstructing the accounting records. We completed the first over the weekend. The main 1C recovery took about a week. The manager estimated that around 80% or more of the data had been recovered—an approximate assessment, not a measured result. Some work on trip sheets is still ongoing.

Here we cover the server, remote access, shared folders, scanning and printing. The accounting recovery story is in the main case study in the series. We divided the work this way: hands on site, brains remote. An IKORG specialist handled the new server and drives on site, while the Claude Code AI agent guided him step by step through a messaging app. A separate specialist helped with the network and MikroTik. The AI agent configured 1C, accounts, shared folders and auditing remotely, under the studio owner's supervision. We logged actions, and destructive operations required the manager's decision.

What happened to the server, and why were the backups lost?

Before the attack, the company ran Windows Server 2019 in a workgroup, without a domain. RDP was exposed to the internet. The attacker logged in using an employee account that also ran the 1C service. The manager suspected that the attacker had entered through that employee's computer. He also reported around 4,600 RDP login attempts in the security log over roughly two hours. Then the connection to the server went down, and by morning the data was encrypted. The attacker also changed the administrator password.

The files received the .aes extension. The ransomware belonged to the Cripton7zp family, and no free decryptor was available. On two NVMe SSDs in RAID, the attacker encrypted the production system, 1C and SBIS archives, documents, spreadsheets and PDFs. Encryption was selective: 1C data processors with the .epf extension and program folders survived.

A separate 2 TB WD Red was considered the backup drive, but it was inside the same server. Its backups were encrypted along with the main system. It was a spare key kept inside the same locked apartment. A copy on an employee's computer was also affected. We found no intact .1CD database files or .dt dumps on the drives, and no shadow copies either. According to the manager, only the configurations remained from the databases in their original form.

The manager reported that the administrator password was later also cracked through FTP and the administrator's files encrypted. The information about this episode comes specifically from his report. Meanwhile, the already established combination of publicly exposed RDP and a personal account used to run a service posed a risk.

The surviving program folders might have seemed encouraging, but an installed copy of 1C, its configuration and a database containing working documents are different things. The program starts, but the accounting records still need rebuilding.

What should you do with infected drives after ransomware?

First, we needed to preserve everything that might still help. We removed the backup HDD and connected it to a clean computer. We used data recovery software to search for deleted originals and saved what we found to another drive. Writing to the drive under examination could overwrite data we had yet to recover.

We did not erase or initialize the encrypted SSDs: we kept them in case a suitable decryptor became available. Whether the data could ever be decrypted was unknown. But keeping the drives meant we could at least return to the task.

During the process, one of the drives was almost initialized. We stopped the operation in time. When a server is urgently needed, the system's offer to “prepare the drive” is easy to mistake for a required step. The interface's politeness is misleading here: that preparation can destroy the only copy of the data, along with the chance of recovery.

We removed the infected drives and installed the new server on a new M.2 drive. This separated the launch of the working environment from the examination of the old media. We no longer had to decide the fate of the remaining data just to make room for Windows.

How did the Windows Server 2025 and 1C installation go?

Overnight from Saturday to Sunday, we installed Windows Server 2025 on the new drive—on site, with guidance from the AI agent through a messaging app. Then we remotely set up 1C 8.5 and MS SQL Server and deployed the accounting database, the carrier's industry-specific database, the Payroll and HR database, and one more database.

At the same time, we restored employee access, shared files, printers and incoming scans. For an office, installation does not end at the Windows welcome screen, however cheerful it may be. The result is being able to open a database, receive a document, save a file and print it.

Along with the system, we changed the remote access rules and checked security. A clean Windows installation with the old exposed RDP would have left the same entry point in place.

By Monday, employees were working on the new infrastructure while document recovery continued. These are separate milestones: the server is available, but the database still has gaps for the lost period. The weekend went into getting the office back to work, not recovering all the data.

How do you secure an RDP connection after a breach?

First, we removed direct access from the internet: we disabled RDP port forwarding on MikroTik. On the server, the firewall allowed connections to port 3389 only from the local network and VPN address pools.

These settings complement each other. The router stops forwarding external Remote Desktop connections, and the server checks which network the request came from. Both sides need checking.

We provided employees with access through a VPN. For remote administration, we used a separate secure channel restricted by connection source. The AI agent's actions were logged, allowing us to trace changes on the server.

Changing the password is only part of the work. You need to check who can reach the service, which accounts can log in and what temporary access remains. Here, we restricted external access on both the router and the server and separated the administration channel from employee connections.

How did we set up a VPN on MikroTik for employees?

Previously, the company used PPTP. After the attack, we began migrating to L2TP/IPsec and prepared ready-to-use connection configuration files for employees. The migration was still underway when we documented the case.

The VPN settings on MikroTik need to work together with the Windows Server rules. A successful connection message is an intermediate result. Next, you check whether the employee can access the required resource and whether unauthorized connections are blocked.

In L2TP/IPsec, IPsec protects the traffic. Configuring the L2TP/IPsec Server on MikroTik therefore covers the tunnel, its protection, accounts and permitted connections. The purpose of the combination is described in the MikroTik documentation.

Ready-to-use files spare employees from configuring the connection manually. Folder and Remote Desktop permissions are set separately: connecting to the office network should not grant access to all company data.

How did we restore shared folders and HP scanning to a network folder?

We created shared scan folders for accounting and logistics and assigned permissions by group. Two HP multifunction printers scan into them—one in accounting, the other in logistics. This ties access to work responsibilities: group membership changes, while the folder rules remain clear.

The multifunction printers received separate service accounts with permissions for their task: writing documents to the designated folder. A scanner has no need for administrator privileges or dependence on an employee's personal account.

We check HP scanning to a network folder across the whole chain: the document went through the multifunction printer, the file appeared in the right place, and the employee opened it. A network connection check covers only part of the path. The device needs write permission; the person needs read permission.

We restored shared files from a cloud backup on Yandex Disk. The volume was about 129 GB: one full backup and three incremental backups. We recovered the documents thanks to a source outside the server, after the internal backup drive had already been encrypted.

Scans also helped reconstruct the accounting records. We are still compiling trip sheets from drivers' reports. We covered how a neural network turns scans into 1C trip sheets separately. This is the next stage after restoring the office's ability to receive and store documents.

How did we connect network printers after reinstalling the server?

The office has five network devices: HP multifunction printers in accounting and logistics, and Kyocera printers in two other departments. They print over IPP. Reserving the devices' addresses on the router is still on the task list. On the server, we disabled client printer redirection in RDP sessions: 25 sessions had their own printers, and the server's printer list was growing for no useful reason.

If an address changes, a workstation may keep looking for the printer at the old one. The printer itself has not moved—it has moved only in the network's view, without announcing its new address. That is why the device, router and computer connection settings need to agree.

We check printing and scanning separately, even on the same multifunction printer. A printed document confirms that printing works; sending a scan to a shared folder requires its own check.

When restoring an office, these tasks are easy to put off until later—1C comes first, after all. But without printing and scanning, employees lose time on routine documents. Checking everyday operations is part of getting the server back into service.

What did we check in the audit, and how did we configure backups?

After installation, we checked accounts, RDP, the firewall, Defender exclusions, password policy, startup entries and traces of AnyDesk. This is a list of checks, not identified violations: the audit helps us understand the settings and remaining access routes.

We set a deadline for the contractor's temporary administrator account in advance and disabled it on schedule: we changed the password and removed it from the administrators group and from RDP access. There had been no logins under that account. It is better to set the deadline immediately: after urgent work, human memory is usually already occupied by the next urgent job.

The 1C administrator's backup software creates nightly SQL backups, and we verified that they succeed. We chose the SIMPLE recovery model because of limited disk space. The compromise has a cost: with SIMPLE, you cannot restore a database to an arbitrary point between backups using a chain of transaction log backups. The limitation is described in the Microsoft documentation.

The practical question for the manager is: how many changes since the last usable backup can the company afford to lose, and how much work can it repeat? The backup schedule needs to be assessed against that.

Nightly SQL backups are running. The next requirement is to monitor where they are stored, who can delete them and whether the database can be restored. A scheduled task confirms only the configuration: the backup's usability and its ability to survive another breach need separate checks.

Why did 1C recovery continue after the office was running?

The server restored the working environment, but we had to reconstruct the lost documents from surviving sources. We restored the industry-specific database from an old backup dating to roughly the end of April. We rebuilt May through September.

We converted around 2,500 sales documents from accounting into orders, service completion certificates and VAT invoices. We reviewed incoming bank payments and linked them to orders. To reconstruct the accounting records, we used sales registers, OCR-processed scans and electronic document interchange records. We added the missing personnel data to Payroll and HR.

The AI worked with scans, email, correspondence and employee responses. The responsible specialists and the manager reviewed disputed data. We turned one-off actions during the work into reusable data processors: as new sources appeared, recovery continued, with checks on ambiguous records.

Duplicates, numbering and payment matching needed separate checks. We cover this in the article on documents and bank statements in 1C. Infrastructure availability and the accuracy of reconstructed accounting records require different verification methods.

The most expensive mistakes

Initializing a drive because the system offers to do it. Here, we barely stopped the operation in time. While needed data may still remain on the media, changing its structure requires a separate decision. We installed the new system on a new drive.

Treating an internal backup drive as sufficient protection. It was exposed to the same attack as the main data. An external backup saved the shared files. The backup strategy needs to be checked against the loss of the entire production system.

Leaving RDP exposed to the internet. Here, it became the attacker's entry point. After recovery, we disabled port forwarding and restricted connection sources in the firewall. Along with changing the password, you need to review who can reach the service.

Running the 1C service under a person's account. This ties service operations to personal access. Services need separate accounts with the required permissions. The original system lacked this separation.

Cleaning the Temp folder of the account running the 1C server. Deleting temporary files that are in use can cause a “File not found …v8_*.tmp” error. If that is the cause, restarting rphost helps. It affects worker processes, so you need to consider the consequences for users before restarting it.

Before cleaning up, reinstalling or changing access, check which data and processes depend on them. This matters especially in a rush: a source accidentally destroyed may turn out to be the only one.

What should you do if ransomware hit you last night?

The purpose of the first actions is to preserve the data and the ability to investigate the old system while preparing a clean working environment.

• Isolate the affected server from the network. Close external access, check exposed RDP and other management channels. Do not connect the only surviving backup to the infected environment.
• Record the current state. Preserve information about errors, file extensions and available storage media. Log subsequent actions to preserve the sequence of changes.
• Stop cleanup and reinstallation on the old drives. Do not agree to initialization. Preserve the media for investigation and decide separately whether to reuse it.
• Compile a list of sources. Look for external backups, cloud archives, electronic documents, email and scans. Check which periods they cover and what can be opened.
• Separate getting the office running from reconstructing the accounting records. Identify the functions needed to resume work and list the lost data separately.
• Prepare a clean environment. Allocate storage for the new system and review accounts and access. Transfer old security settings only after checking them.
• Check work operations. Separately check employee login, opening a database, folder access, scanning and printing.
• Assign responsibility for disputed data. Automatically reconstructed documents require reconciliation. Ambiguous records must be confirmed by the person responsible for the relevant area of accounting.
• Check backups. Establish where they are stored, whether an attacker can access them and whether restoration is possible. Document the strategy's limitations.

The manager will benefit from two lists: what already works and what has not yet been restored. This keeps an accessible desktop from becoming a premature completion checkmark and prevents the review of the last document from holding up the office's return to work.

Frequently asked questions

Can files with the .aes extension be decrypted?

The extension alone does not tell you. This case involved Cripton7zp, and no free decryptor was available. We preserved the drives and restored operations through a clean system and available data sources.

Can a server be restored over a weekend?

In this case, employees were working on the new server by Monday. The main 1C recovery took about a week, and some documents were reconstructed later. That is the timeline for this particular job; in another case, it will depend on the state of the system and the surviving sources.

Does RAID protect against ransomware?

RAID does not replace a separate backup: files accessible to the system remain accessible for encryption. Here, data on two NVMe SSDs in RAID was affected. Recovery requires independent, usable sources.

Is installing Windows Server 2025 in place of the old system enough?

No. After a clean installation, you need to check access, services, accounts, network rules and backups. Here, alongside the system, we restored office functions and closed external RDP access.

Can recovery be assigned to an AI agent?

Here, Claude Code worked under the IKORG owner's supervision, with an action log. Destructive operations required the manager's decision, and responsible employees confirmed disputed data. Access control and human review remained mandatory parts of the work.

Need to restore a server and office after an attack?

At IKORG, we help restore the server environment, employee access, 1C, shared folders, scanning and printing. The AI agent works under the studio owner's supervision, with an action log and approval for destructive operations.

If your server is encrypted or your office is only partly operational, contact us. Describe what stopped working and which backups survived. We will examine the available sources and determine the order for restoring the infrastructure and data.