The company's engineering director, Mark Loman, said in a detailed blog post, that a new kind of protection had been devised to block code being injected from one memory region with only read/write permissions to a second region where it would also have execute permissions.

He said that from 2003 onwards, CPUs had a technology called NX bit that partitioned memory regions for either processor instructions or storing data. Windows support for this tech was called Data Execution Prevention or DEP.

"For example, a memory region that contains an image shown in the Web browser does not have code execution permissions, whereas the region that contains the core application — the Web browser itself — can execute code," he explained.

Applications needed workspaces within memory to operate and this was dynamically allocated to temporarily store or cache data. This was called the Heap and it would increase or decrease as an application did what it was tasked to do.

"Image memory is normally protected with Execute/Read permissions. Heap memory with only data in it is typically allocated Read/Write permissions. When a Heap memory region is populated with code, permissions are set to Execute/Read/Write or Execute/Read," Loman said, pointing out vital differences between the two.

Loman said DEP ensured that data-only regions of memory could not execute code.

"Because of DEP, every running application ('process') that requires more memory, for instance to unpack code, must allocate or mark this additional memory region with code execution permissions before it can hand over code execution to this region," he said.

"If this memory region does not have at least Execute/Read permissions, an exception is raised by the processor hardware and the process is terminated by the operating system."

In the case of malicious applications, like ransomware, they were generally injected into Heap memory. What Sophos had developed was a means of blocking additional memory allocation when the request came from existing Heap memory, he said.

Called Dynamic Shellcode Protection, it would generate data that helped threat responders to trace the initial access point and also the command-and-control server of the malicious application.

"When a process, regardless of whether it is malicious or benign, violates the Heap memory allocation barrier, the Dynamic Shellcode Protection will block it and notify defenders. Security professionals can then take a closer look at what is going on," said Loman.

"The new protection is not meant as a silver bullet for all attacks, but it does mean that adversaries face a new obstacle that blocks a fundamental behaviour of their stealthy code.

"We hope this will make attackers' jobs harder and more complicated. The Dynamic Shellcode Protection does not rely on the cloud or machine learning. As such it represents a paradigm shift in the ongoing battle against many obfuscated malware and memory-delivered post-exploitation agents, including Cobalt Strike Beacon."