What to do when systems are encrypted: contain, assess the scope, recover from reliable backups and rebuild an environment that will not fall the same way again.
After an encryption event, the priority is restoring operations without reintroducing the problem. Restoring quickly onto the same compromised environment usually ends in a second incident days later.
What we usually find
It is unclear which systems are affected and since when.
Backups may be attached to the same compromised domain.
Pressure to resume invoicing as soon as possible.
Notification and record-keeping obligations.
Which companies it fits
Companies that have suffered an encryption event, or that want to define in advance how they would act if one occurred.
If you have an incident in progress, call our contact number; if you want to prepare, we will review backups and access.
Isolating devices and cutting communications to stop propagation.
Scope assessment
Which systems and data are affected and which backups are reliable.
Orderly recovery
Server rebuild and restoration by business priority in a clean environment.
Subsequent hardening
Review of access, two-factor authentication, segmentation, immutable backups and continuous monitoring.
How it is deployed
1First response and containment.
2Inventory of damage and of available backups.
3Recovery plan in order of criticality.
4Restoration and validation with each area owner.
5Report and hardening plan to prevent a repeat.
Real-world scenarios
The first hours after encryption is detected
Containment comes first: isolating affected machines from the network, preserving evidence and avoiding shutdowns that would destroy information useful for analysis. In parallel, the state of the backups is verified and the recovery order is decided. Rushed decisions at this stage are what lengthen the outage.
Returning to service by priority
Recovery is not simultaneous. Identity and network are restored first, then the application carrying the main activity, then the rest, verifying at each step that the recovered environment is clean before reconnecting it. That priority list is agreed with the company before an incident, not during one.
What Seintec does during and after the incident
During the incident Seintec contains the spread, assesses the state of the backups, plans recovery by priority and executes it, verifying the restored environment is clean before returning it to production. Afterwards a technical report sets out the timeline, what was recovered and the corrective measures with dates. In-depth forensics and legal assessment call for specific expertise: where a case requires them, we say so from the outset and coordinate with the right party rather than claiming a scope we cannot cover.
What is at stake if it is left unaddressed
Restoring onto a compromised environment
Returning data to a network where the attacker still has access leads to a second encryption within days.
Backups reached by the attack
Backups accessible with domain credentials are a primary target. Copies must sit beyond the reach of compromised accounts.
No emergency contact
Not knowing who to call, and with what authority, wastes hours at the point where they are worth the most.
That cannot be guaranteed. The outcome depends on the scope of the encryption and on the quality and age of the available backups.
Do you recommend paying the ransom?
No. Paying does not ensure recovery and funds criminal activity; the approach is to recover from reliable backups.
Is there an obligation to notify?
There may be, depending on the data and sector. That is a legal assessment for the company's legal adviser.
How long before we can work again?
It depends on volume, backup condition and the number of systems. Whatever sustains invoicing is prioritised.
Should the ransom be paid?
Paying guarantees neither recovery of the information nor that the data will not be published, and it sustains the attacker's business model. The general recommendation from the competent authorities is not to pay and to report the crime. The decision rests with company management, ideally with legal advice and after assessing the real state of the backups.
Does the incident have to be reported?
Where personal data is affected there are notification obligations with defined deadlines, and filing a criminal complaint is often advisable too. Seintec supplies the technical detail of the incident and of what was restored; the legal assessment and the notification itself rest with the company and its legal advisers.
How do we stop it happening again?
With the measures that are usually missing in real cases: multi-factor authentication on every remote access, backups outside the reach of the domain, network segmentation, a review of administrator rights, current patching and someone watching the alerts. After the incident, what failed is documented and each correction is scheduled with a date.
Can recovery be engaged without being an existing client?
Yes, although the response is always better when the environment is already known. In a new case, the first phase maps the systems and the real state of the backups, which determines what can be recovered and by when. That assessment is delivered before any plan is committed.
Contact the technical team
If you have an incident in progress, call our contact number; if you want to prepare, we will review backups and access.