At 02:14 on a Saturday, a finance workstation in a branch office runs a scheduled report. Nothing unusual. The user is asleep. The machine is patched to whatever level the last maintenance window allowed, three months ago, because the branch runs a core banking client that breaks on certain updates.
A macro in a spreadsheet the user opened on Thursday reaches out, pulls an encoded payload, and hands it to PowerShell. No file is written to disk. The payload unpacks in memory, reflectively loads a module, and injects into a signed, trusted process that is already running and already allowlisted. From that point on, everything the attacker does is done by software your organisation bought, installed and trusts.
The endpoint agent sees a legitimate process making legitimate API calls. Telemetry is generated, sent to the cloud console, scored, and queued behind four hundred other events, most of them noise, because the SOC is three people covering five countries and Saturday night is one analyst on call.
By Monday the attacker has credentials, has mapped the file shares, and has been inside for fifty-eight hours. Nothing has been detected as malicious, because nothing has done anything unambiguously malicious. The encryption has not started. It will start when the operator decides it should.
None of this is the endpoint tool failing. It did exactly what it was built to do. The problem is what it was built to do.
The gap between the org chart and reality
On paper, most organisations in our region have solved endpoint security. There is a line item for it, an EDR or XDR platform deployed in the last few years to replace a signature-based antivirus everyone agreed was no longer adequate, a dashboard, and either a managed detection service or a plan to buy one.
The architecture diagram says: prevent, detect, respond, recover. Four boxes, left to right, each one catching what the previous one missed.
The reality is that three of those four boxes contain the same mechanism. Detection. Modern endpoint platforms prevent what they can recognise, detect what they can characterise, and respond to what they have alerted on. Underneath the different marketing language, the engine is the same: observe behaviour, compare it against models of known-bad, produce a confidence score, act above a threshold.
That mechanism is probabilistic. It has to be. A behavioural engine that fired on every ambiguous action would generate so many false positives that nobody would use it. So the threshold is tuned, and tuning a threshold means deciding, in advance, what level of suspicious activity you are willing to let through.
Attackers understand this better than most defenders do, because they can buy the same products. Endpoint detection tools are commercially available. A ransomware affiliate can license a copy, stand it up in a lab, and iterate on their loader until it runs clean. They are not guessing at your detection logic. They are testing against it, the same way a developer tests against a unit test suite, until the build passes.
So the question is not whether your endpoint platform is good. It probably is, at what it does. The question is what happens to a technique engineered in advance to produce no detection at all. Detection does not degrade gracefully there. It produces silence, and silence is indistinguishable from safety. In the window between the moment code executes and the moment a person decides it was hostile, everything the attacker needs to do can already be done.
The real challenges
1. There is no file to scan
The whole scanning model assumes an artefact. Something lands on disk, gets hashed, gets compared, gets sandboxed. Fileless attacks remove the artefact. The payload arrives as script, as a registry value, as a WMI subscription, as shellcode passed directly into the memory space of a running process, and it never touches the filesystem in a form anything can inspect.
Walk through it on a real endpoint. A user in a manufacturing plant opens an invoice attachment. The document invokes a scripting host, which pulls a base64 blob over HTTPS from a domain registered nine days ago with a clean reputation. That blob is decoded in memory and reflectively loaded, bypassing the operating system’s normal module-loading path entirely. No DLL on disk, no executable, just a running trusted process now containing code that was never written down anywhere your tools can look.
Scanning cannot help here, because scanning needs something to scan.
2. The attacker is using your own tools
Living-off-the-land is the most reliable evasion strategy available today and requires no malware at all. PowerShell for execution. WMI for lateral movement. Certutil to fetch and decode. BITS to transfer. Task Scheduler for persistence. Native remote administration utilities to move between hosts. Legitimate cloud storage clients and file transfer utilities to exfiltrate.
Every one of those is a tool your own administrators use, so your endpoint platform cannot simply block them without breaking operations. Instead it looks for anomalous usage patterns, which brings you straight back to the threshold problem.
Consider an IT team of six supporting eleven hundred users across three sites. They use remote administration tooling daily, script bulk changes, and run maintenance jobs at odd hours because the plant only stops on Sundays. When an attacker uses identical tooling, at a similar hour, from a machine that belongs on the network, the behavioural signal is not weak. It is genuinely ambiguous, and no amount of tuning resolves ambiguity that is real.
3. The window is measured in minutes, the response in hours
Detection and response is a sequence with human beings in it. Telemetry is collected, uploaded, correlated, scored, queued, triaged, escalated, decided, contained. Even with automated containment playbooks, there is latency at every hop. Ransomware operators have compressed their side of the sequence deliberately. Once the operator decides to act, initial access to full encryption across a network can happen inside a single shift.
Now overlay staffing. Across South Asia and the Middle East, the security operations problem is not budget alone, it is people. Experienced analysts are scarce, salaries are competitive with Gulf and Singapore markets that pull talent away, and most organisations we work with run security operations with a handful of generalists who also own patching, identity, network and audit response. Twenty-four hour coverage is aspirational at three in the morning on a public holiday.
A control that depends on someone reading an alert has a response time equal to the availability of that someone.
4. The systems you cannot patch are the systems they want
Every organisation has an estate it does not talk about in board presentations. A hospital with imaging modalities running an operating system that went out of support years ago, where the vendor will not certify a newer build and replacing the machine is a capital project. A plant with an HMI and a historian on a Windows version nobody will touch because the line integrator is no longer in business. A bank with a reconciliation server that must not reboot inside the settlement window. A utility with air-gapped segments where nothing can call home for updates.
These systems often cannot host a modern heavyweight agent at all. They lack the operating system instrumentation newer detection engines depend on, cannot spare the resources, or sit under a support agreement forbidding third-party software.
So they get compensating controls: segmentation, restricted access, a documented risk acceptance. Then someone connects a laptop to commission a change, or a segment turns out to be less isolated than the diagram claimed, and the least defended machines in the estate turn out to be the most reachable.
5. Virtual desktops and shared infrastructure change the maths
VDI was supposed to simplify endpoint security. In practice it changes the economics. A scanning agent that costs a few percent of CPU on a physical laptop costs that on every session on a shared host. Multiply by session density and the security agent becomes a capacity planning problem, so teams trim scan schedules, exclude paths and reduce inspection depth until the user experience is acceptable.
A persistence assumption breaks too. Non-persistent desktops reset, which is often a security benefit, but it also means behavioural baselines never mature and forensic evidence disappears on logoff. An attack that executes, achieves its objective and lets the session recycle leaves very little to investigate.
6. Cloud dependency at the worst possible moment
Most detection engines lean on cloud services: reputation lookups, model updates, sandbox verdicts, correlation across the customer base. This works well when connectivity is good. It works less well for a branch on a congested link in a secondary city, a remote site on satellite, a manufacturing segment deliberately isolated from the internet, or any environment where an attacker’s first move is to disrupt egress. Endpoint tampering tooling in circulation is designed precisely to sever an agent’s ability to report, so the console shows a quiet endpoint rather than a compromised one.
A control whose effectiveness varies with your WAN link cannot be planned around uniformly across a distributed estate.
Why the usual fix makes it worse
When the gap becomes visible, the standard responses are all variations on the same idea: more detection.
Add another detection layer. A second engine, a network sensor, deception, an overlay to correlate the others. Each is defensible alone. Collectively they multiply the volume of probabilistic signal flowing into a team that was already the bottleneck, and correlation of uncertain inputs produces a more confident-looking uncertain output.
Buy managed detection and response. This genuinely helps with coverage and is often the right decision, but it does not change the mechanism. An external SOC still receives telemetry from a detection engine, still applies judgement, still calls you before acting on a production system. You have outsourced the analyst, not the dependency on analysis. For attacks engineered to produce no anomalous telemetry, there is nothing for the external team to see either.
Tighten the thresholds. Lower the confidence bar so more gets caught. This works for about two weeks, until false positive volume forces someone to write exclusions, and exclusions are permanent in a way tuning decisions rarely are. Six months later nobody remembers why a directory is excluded, and attackers have learned to look for exactly those directories.
Patch faster. Correct in principle and constrained in practice. You cannot patch an out-of-support medical device. You cannot patch a production line during a shift. You cannot patch a zero-day. Even a mature programme has a window between disclosure and deployment, and that window is exactly where exploit code lives.
Restore from backup. Necessary, and under-tested nearly everywhere. But backup answers the encryption problem, not the extortion problem. When data has already been exfiltrated, restoring your systems does not restore your position, and attackers target backup infrastructure and shadow copies early precisely because recovery is your leverage.
The common thread is that all five responses stay inside the same paradigm. They add capacity to detection. None of them adds a different mechanism. Defence in depth, properly understood, means layers that fail in different ways, not more layers that fail the same way.
How Morphisec approaches this differently
Morphisec starts from a different question. Instead of asking how to recognise a malicious process faster, it asks what would have to be true for the attack to fail at execution, without anyone recognising anything.
The answer is in the memory runtime. Every in-memory attack, whether a fileless loader, an exploit chain, a reflective injection or a packed ransomware payload, depends on the target environment being predictable. Exploit code needs to know where system structures, libraries and functions sit in a process’s memory space. That predictability is not an accident. It is what makes software work, and it is what attackers build against.
Morphisec’s Automated Moving Target Defense morphs application memory at load time. As an application loads into memory, the process structures are restructured so the memory layout is unpredictable to anything that did not participate in the morphing. Legitimate application code is updated to use the morphed resources and continues to run normally. A skeleton of the original structure is left in place as a trap.
When malicious code executes and reaches for the resources it expects to find, they are not there. The attack fails, immediately, at execution. It is then trapped and logged with full forensic detail.
The consequence worth sitting with is what this model does not require. No signature, because nothing is being identified. No behavioural model, because nothing is being characterised. No cloud lookup, reputation service or sandbox verdict. No analyst, queue or response time. The attack is not flagged for someone to assess later. It does not run.
Morphisec describes this as deterministic prevention as opposed to probabilistic detection, and that distinction is the entire architectural argument. A probabilistic control asks whether this is likely to be malicious. A deterministic control removes the precondition the attack depends on. The first can be studied and evaded by an adversary with a lab copy of your product. The second cannot be reverse-engineered in advance, because the morphing is not a static configuration an attacker can obtain and analyse.
What that architecture makes possible
Because prevention happens locally in the runtime, protection works offline and in air-gapped environments, with no dependency on a cloud console for the control itself to function. A branch on a poor connection, an isolated OT segment and a corporate laptop all get the same enforcement.
Because there is no continuous scanning, the resource cost is low. Morphisec states the agent runs at under 1% CPU utilisation, operates in user space, and requires no reboot to deploy. On shared virtual desktop infrastructure and production servers where every percentage point of overhead is a capacity conversation, that is not a cosmetic difference.
Because the mechanism does not depend on newer operating system instrumentation, it extends to the estate that modern detection tooling struggles with. Morphisec is explicit that the machines which cannot take a heavyweight agent are the ones attackers want most: end-of-life Windows, clinical and biomedical devices, OT and manufacturing endpoints, air-gapped hosts. Morphisec positions AMTD as a virtual patching and compensating control for unpatched vulnerabilities, protecting the system even before a vulnerability has been discovered and a patch developed. For an organisation carrying a legacy estate it cannot upgrade this year, that changes what risk acceptance actually means.
And because it is a different mechanism rather than a competing one, it layers underneath what you already run. Morphisec is designed to work alongside existing EDR, XDR and next-generation AV rather than replace them, described as a safety net and last line of defence that complements the technology you use today while catching the evasive attacks those tools miss. Nobody rips anything out. The detection stack keeps doing what it is good at, which is visibility, investigation, hunting and response, while a deterministic layer sits beneath it handling the class of attack detection was never designed to see.
The wider suite
AMTD is the foundation, but Morphisec packages it within the Anti-Ransomware Assurance Suite, which addresses the ransomware lifecycle in named layers.
Adaptive Exposure Management works before an attack, prioritising vulnerabilities using contextual exposure alongside EPSS and the CISA KEV catalogue, validating that security controls are genuinely deployed and correctly configured, and surfacing misconfigurations, risky software inventory, end-of-life components and privileged account exposure. That matters wherever the honest answer to “is the agent installed everywhere” is “we think so”.
Infiltration Protection is the AMTD runtime memory layer, preventing fileless threats and blocking privilege escalation, credential theft and the hacking tools operators rely on during intrusion.
Impact Protection and data exfiltration control addresses the endgame: preventing encryption and destruction, protecting Volume Shadow Copy backups from deletion, and governing dual-use transfer utilities that are legitimate administrative tools and exfiltration tools at once.
Adaptive Recovery intercepts encryption keys in real time so files can be restored, and preserves forensic evidence in tamper-proof storage.
The suite also extends into Adaptive AI Defense, covering discovery and governance of the AI tools, agents, local models, browser extensions and MCP connectors now appearing in enterprise environments. All of it is delivered through a single lightweight agent and one management console, across Windows, Windows ARM, macOS and Linux, with a deployment timeline Morphisec measures in days. Morphisec also offers a commercial anti-ransomware guarantee on protected endpoints, worth reading closely with your legal team, but telling in itself about the confidence a deterministic model allows.
What this looks like in practice
Return to the branch workstation at 02:14, with a morphing layer installed underneath the existing endpoint platform.
- The user opens the same spreadsheet on Thursday. Nothing changes about the delivery.
- The macro fires and invokes the scripting host. Still legitimate, still allowed.
- The encoded payload is fetched over HTTPS and decoded in memory. No file is written, and nothing is scanned, because there is still nothing to scan.
- The payload attempts to reflectively load its module and inject into the running trusted process. This is the step everything depends on.
- The injected code reaches for the memory structures it was compiled to expect. They have been morphed, and the resources are not where they should be.
- Execution fails. Not quarantined, not scored, not escalated. The chain terminates at execution, on a Saturday night, with no analyst involved.
- The attempt is trapped and logged with full forensic detail.
- On Monday the security team reads a prevention record rather than opening an incident. The threat intelligence is still valuable. The breach did not happen.
The difference between the two versions of this story is not detection quality. It is that in the second version, success never depended on anyone noticing anything.
Mapping the problem to the control
Challenge |
How Morphisec addresses it |
| Fileless, in-memory payloads leave nothing to scan | AMTD morphs application memory at load time, so attacks fail at execution with no file, signature or behavioural model needed |
| Living-off-the-land abuse of trusted native tools | Infiltration Protection blocks credential theft, privilege escalation and intrusion tooling at the memory layer; Impact Protection governs dual-use transfer utilities |
| Dwell time between execution and analyst response | Deterministic prevention removes the detect-triage-respond dependency for this attack class; there is no queue to sit in |
| Unpatched, end-of-life and OT-adjacent systems | Virtual patching and a compensating control for unpatched vulnerabilities, covering end-of-life Windows, biomedical, OT and air-gapped hosts |
| VDI and servers where agent overhead is a capacity problem | Under 1% CPU, user-space operation, no reboot required to deploy |
| Poor connectivity, isolated segments, tampering with cloud reporting | Local prevention works offline and air-gapped, with no cloud lookup required for enforcement |
| Backup and shadow copy destruction before encryption | Impact Protection defends Volume Shadow Copy; Adaptive Recovery intercepts encryption keys for restoration |
Who benefits most
Banks, insurers and financial institutions under RBI, SAMA, Central Bank of Sri Lanka, Bangladesh Bank, MAS and UAE Central Bank expectations, where uptime windows are narrow, branch estates are distributed, and scrutiny of ransomware readiness has sharpened.
Hospitals and healthcare groups carrying imaging and diagnostic equipment on operating systems that cannot be upgraded, where the risk of an unavailable system is measured in patient outcomes rather than downtime hours.
Manufacturers, utilities and logistics operators with OT-adjacent Windows endpoints, engineering workstations and historians on continuous production schedules, where a maintenance window is a commercial negotiation.
Government agencies and telcos with large, mixed-generation estates, restricted or air-gapped segments, and security teams that are thin relative to the endpoint count they are accountable for. More generally, any organisation whose honest constraint is not tooling quality but the number of people available to act on what the tooling produces.
The layer underneath
The endpoint security conversation has been stuck on one axis for a decade: how quickly can we detect, how quickly can we respond. Both numbers have improved. Neither addresses an adversary who has decided, quite rationally, to build attacks that produce nothing worth detecting.
Prevention at the memory layer is not a better detector. It is a different question asked at a different point in the chain, at the moment of execution rather than after it. That is what makes it a genuine additional layer rather than another instance of the same one. If your existing controls and your new control fail for the same reason, you have redundancy, not depth.
EGUARDIAN distributes Morphisec across Sri Lanka, India, Bangladesh, Singapore, the UAE and the wider Middle East, working with partners and end customers to scope deployments against the estates that are actually hard: the legacy systems, the constrained segments, the production servers and the branch endpoints that never fit the standard rollout.
Talk to our experts at EGUARDIAN. If you are running a capable detection stack and a small team, and you are not confident about what happens between execution and response, let us talk through your estate, your constraints and where a deterministic prevention layer would actually change your risk. Reach out to us at hello@eguardian.com.
