When a company gets encrypted, the date everyone remembers is the morning it was discovered. That is the last stage, not the first. The starting point usually sits much further back, in the mailbox of someone who does not work in IT, and the sequence in between consists of separate steps, every one of which can be interrupted.
That is exactly why the chain is worth understanding. Not to reproduce it, but because effective defence is never a single product. It is a set of checkpoints placed at several stages, so that clearing one is not enough to reach the destination. What follows describes each stage at the level a defender needs, paired with the controls that stop it.
Stage 1: Initial access through email
Email remains the most common way in because it is the one channel a business is obliged to keep open to strangers. A message arrives from outside, written in familiar commercial language, referring to an invoice, a job application or a delivery change, and asks the recipient to open an attachment or sign in to a page that resembles an internal system.
Two outcomes are possible here: the recipient’s device begins running code controlled from outside, or the recipient’s credentials are captured. Both lead to the same thing, a legitimate foothold inside the organisation.
Controls that break this stage:
- Gateway filtering with link analysis performed at click time, since a link can be harmless when the message is delivered and hostile a few hours later.
- Blocking or sandboxing file types the business does not need, particularly executable content and multi-layer archives.
- Sender authentication configured to the common standards, which reduces the ease of impersonating your own domain.
- Clear external-sender labelling, a simple measure that meaningfully affects messages impersonating executives.
- Training focused on reporting behaviour rather than detection ability. The metric that matters is how many people press the report button and how quickly, not how many avoided being fooled. An organisation with a working report channel learns about a live campaign before automated systems flag it.
Stage 2: The endpoint becomes a foothold
Once present on a workstation, the next objective is to survive reboots and maintain an outbound channel. Conceptually that means arranging for code to be re-executed automatically and establishing outbound traffic that resembles ordinary activity.
Controls that break this stage:
- Endpoint detection and response deployed with blocking genuinely enabled, not merely alerting. Many organisations run such tools in monitor mode for months out of concern about user impact.
- Removing local administrator rights on workstations. This is one of the few low-cost, high-impact measures available, because it substantially limits the ability to install persistence.
- Application control over what may execute, at minimum in directories the user can write to.
- Monitoring for unusual outbound connections: newly seen destinations, regular periodic traffic patterns, or unusually large volumes leaving a single workstation.
- Short patch cycles for browsers, office suites and operating systems, since these components are the ones directly exposed to outside content.
Stage 3: Credential theft
The initial foothold is almost always a low-privilege account. Going further requires better credentials. The usual supply is not sophisticated technique but accumulated untidiness: passwords saved in browsers, text files holding logins on a shared drive, automation scripts with embedded passwords, internal runbooks that include credentials, and identical local administrator passwords across every workstation.
Controls that break this stage:
- Phishing-resistant multi-factor authentication on every external entry point and every administrative action. Factors based on cryptographic keys or hardware are considerably more durable than one-time codes delivered by message.
- Unique local administrator passwords per machine, centrally managed and rotated automatically. This removes the value of reusing one credential across hundreds of hosts.
- A secrets manager for systems, so passwords stop living in scripts and configuration files.
- Scanning shared drives and internal repositories for stored credentials, treating the results as remediation work rather than as grounds for blame.
- Alerting on identity anomalies: sign-ins from new locations, repeated failures followed by success, or an account suddenly reaching systems it has never touched.
Stage 4: Privilege escalation
With better credentials, the next objective is administrative control at the domain or cloud platform level. Conceptually this tends to happen through one of three routes: a service account with excessive rights, an unpatched system that permits local escalation, or a permission configuration that lets an identity modify its own entitlements.
Controls that break this stage:
- Eliminate standing administrative rights. If elevated access exists only in short approved windows, the opportunity to seize it narrows dramatically.
- Separate administrative accounts from daily-work accounts, and never use an administrative account to read email or browse the web.
- Use dedicated privileged access workstations for administrative operations, isolated from the ordinary desktop environment.
- Review the effective permissions of service accounts on a schedule, especially any account able to modify permission configuration.
- Alert on permission changes themselves: additions to administrative groups, attachment of high-privilege policies, or creation of a broadly entitled identity.
Stage 5: Lateral movement
Elevated rights only matter if they lead somewhere that holds important data. This stage is the crossing from the user zone into the server zone, usually via the same legitimate administrative mechanisms the operations team uses daily. That is what makes it hard to see: the activity looks like normal administration, and differs only in who is doing it and when.
Controls that break this stage:
- Network segmentation by function with default-deny between zones. The end-user zone should have no direct route to application servers and databases.
- Blocking workstation-to-workstation connectivity entirely, a restriction that rarely affects work and removes one of the most common spread paths.
- Routing all administrative access to servers through a broker that records the session and requires multi-factor authentication.
- Alerting on context rather than action alone: an administrative account signing in to a server it has never touched, or at an unusual hour, is worth investigating even when the action is permitted.
- In cloud environments, keeping production in its own account so that an identity in a non-production environment has no natural route into production.
Stage 6: Discovery of data and backup infrastructure
Before encryption, the objective is to understand the environment: where the important data lives and, more importantly, where the backups live. This stage determines how severe the whole incident becomes. If the backup infrastructure sits inside the same administrative domain and can be deleted with credentials already obtained, the recovery option disappears before any encryption begins.
Controls that break this stage:
- Separate backup infrastructure entirely from the production authentication domain. Backup credentials must be different and must not be stored on the systems they protect.
- Use immutable backups with retention that cannot be shortened, so deletion is not an available operation for any identity.
- Alert loudly on anything touching backup configuration: schedule changes, reduced retention, resources removed from protection scope, or deletion of recovery points.
- Watch for broad enumeration activity: an account listing large numbers of file shares, or calling resource-listing APIs across many services within a short window.
- Monitor outbound data volume, since copying data out typically occurs at this stage, before anything visible has happened.
Stage 7: Encryption
The final stage is usually the fastest, and it is the only one the victim sees. By this point most defensive opportunities have already passed. What remains is limiting scope and shortening recovery.
Controls that limit the damage:
- Behavioural blocking on endpoints, recognising abnormal bulk file access patterns rather than relying on signatures.
- Frequent filesystem and database snapshots with restricted delete rights, adding a recovery layer beyond the primary backup.
- A written and rehearsed isolation plan: who is authorised to disconnect a network segment, by what mechanism, and how the organisation communicates internally when internal mail is unavailable.
- A recovery procedure validated by regular exercises, with recovery time objectives confirmed by measurement rather than assumption.
What to take from the chain
The most important observation is that the chain has many stages, and each one takes time. The interval between first access and encryption is the single largest defensive asset an organisation has, but only if it can see what is happening during that interval.
For most companies the sensible order of priority is therefore: phishing-resistant multi-factor authentication, elimination of standing administrative rights, segmentation sufficient to block the path from user zone to server zone, immutable backups separated from the main administrative domain, centralised logging in a location that cannot be erased, and a rehearsed response plan. None of these is a single product, and none needs to be finished before the next one begins.
How HiTechCloud can help
HiTechCloud is an AWS partner and a Google Premier Partner, and operates in-country infrastructure. We help organisations design network segmentation and environment separation in the cloud, implement immutable backups isolated from the production administrative domain, set up centralised logging for detection and investigation, and rehearse recovery procedures to confirm real recovery times. Contact us if you would like an assessment of your current position.
