Memory Allocation and RW → RX Transitions

We have discussed the call stack; now, let’s go a layer deeper and look at memory itself.

One of the things EDRs monitor when analyzing process behavior is memory permissions and their changes.

What exactly do RW and RX mean? Each memory segment can have different permissions:

R = Read
W = Write
X = Execute

For example:

RW

Means:

Read + Write

The program can read and modify the data in this section but is not intended to execute code from it.

Or:

RX

Means:

Read + Execute

It can read data and execute CPU instructions from that section but should not be able to modify the page's content.

Conceptually, we might see a sequence like this:

Memory Allocation
↓
RW
↓
Write Data
↓
Permission Change
↓
RX
↓
Execution

This means a memory segment was initially writable, and then its permission was changed to allow execution.

This change alone does not imply the presence of malware; for instance, some entirely legitimate software applications generate or compile code for various reasons.

JIT
is a key example.

Some runtimes utilize a technology called:

JIT = Just-In-Time Compilation

Here, the program might generate a portion of code during runtime and require suitable memory to execute it.

So:

RW → RX

can occur even in legitimate software.

Therefore, a high-quality EDR should not simply conclude:

RW → RX = Malware

Because that logic is about as accurate as saying anyone wearing a hoodie is a hacker 😂

What matters is the context.

An EDR
usually doesn't look at just a single event.
For example, imagine a sequence like this:

Process
↓
Memory Allocation
↓
Write
↓
Protection Change
↓
RX Memory
↓
Thread Activity
↓
Call Stack
↓
Network Activity

Each step might be perfectly normal on its own,
but when several unusual behaviors... ...they acquire greater analytical value.

For this reason, modern detection looks more like this:

Event
+
Context
+
Process History
+
Memory Information
+
Thread Information
+
Call Stack

RWX
Sometimes, a memory segment's permissions might look like this:

RWX

Meaning:

Read
Write
Execute

In this case, the memory region is both modifiable and executable.

From a security perspective, this situation is usually more critical because of an important principle known as:

W^X

Meaning:

Writable XOR Executable

Simply put:

It is best for a memory region not to be both Writable and Executable at the same time.

Of course:

RWX ≠ Malware

And:

RW → RX ≠ Malware

These are merely signals, not a definitive conclusion.

DEP
One of Windows' key mechanisms:

Data Execution Prevention

Its goal is to ensure that memory segments not intended to run code cannot be executed.

For instance, if a segment is only:

RW

...we do not expect the CPU to execute instructions from it as it would a standard code region.
Thus, memory permissions are part of the operating system's security model, not just a value within a debugger.

EDR
What exactly does it focus on? When analyzing a memory region, information such as the following can be significant:

Process
├── Memory Type
├── Protection
├── Allocation History
├── Thread
├── Thread Start Address
├── Call Stack
├── Loaded Modules
├── Parent Process
└── Process Behavior

For instance, from an analytical standpoint, these two scenarios are not the same:

Application
↓
JIT Activity
↓
RW → RX

Compared to:

Unknown Process
↓
Private Memory
↓
Write
↓
RW → RX
↓
Suspicious Thread Activity

EDR systems focus precisely on this contextual difference.

Important Note:
When viewing a memory region in a debugger or memory viewer, do not look solely at the address.

Examine these attributes as well:

Address
Size
Protection
Type
State
Backing
Owner Process
Thread Relation

For example:

0x000001A...
Size: 0x5000
Protection: RX
Type: ...
State: ...

This information helps you understand the nature of the memory region you are dealing with.

So, for now, keep this mental model in mind: