Can malware override and execute any memory location or it has to be specific?

Question

Rather primitive Malware using Python3 and similar already available software on the victim's machine (which can also be compiled using PyInstaller/pycom if not) has the capability to override the user's processes in memory while they're running.

There's even a library for that. You can of course even use integrated standard library commands from Python3 to do the similar, but pymem makes it easier in my opinion. To quote: "Python can call any Microsoft API and perform process injection using the classic VirtualAlloc(), CreateRemoteThreat(), etc."

So it seems this attack vector is a subcategory of process injection called Process Hollowing. The issue seems only to be on Windows, since it was a design choice for antiviruses and etc to be possible to inject into processes.

So my questions are:

• Can malware override and then execute from any memory location of a process or it has to be specific?
• Since the possibility to do this (please correct me if I'm wrong) only exists on Windows (according to the MITRE ATT&CK page too), how do I mitigate/protect against this threat vector on a Windows machine?
• Also when we're talking about "hijacking" the process for nefarious purposes are we talking here about virtual or physical memory?
• How do you successfully monitor against process manipulation? (yes, MITRE ATT&CK, mentions it but that's about it)

Answer 1

Both Windows and Linux allow process injection, the difference is that Linux is more strict in checking the permissions.
In fact, under Linux, it is equivalent to the PTRACE_ATTACH check, which by default is only granted to root (via CAP_SYS_PTRACE) or to a parent process.

Under Windows, a process can access another (non-protected) process of the same user at the same integrity level, by default.

This attack vector is process injection, of which, Process Hollowing is a specific type.

If allowed, a malware can read/write any read/rewritable page of the target process but in order to gain execution, it must do so carefully.
Typically a whole new buffer is allocated and a new thread is created to execute the shellcode.
Another possibility is hijacking, this can be done by altering a function pointer (e.g. an entry in a vtable), a return address, or simply by altering the context of one of the target's threads. Of course, hijacking will compromise the target process' functionality.

Checking for the integrity of a process is expensive in general (so it cannot be done in real-time) and doing it from the process itself is akin to white-box cryptography.
It is also difficult. In principle, you only need to measure the code and data of the process but while this is easy for code and read-only data, it is hard for things like the stack or heap memory, where values from outside (input) creep in and there is no established set of allowed vs non-allowed values (think of an array of C++ objects with vtables).
What is actually done is to properly set the DACL of a process object to deny other processes from accessing it. Another possibility is elevating the integrity level of the process.
This prevents any modification in the first place and avoids the need to check the process memory for any altered value. If you don't trust higher privileged processes too (e.g. system services or the OS) you need a whole framework for remote attestations, like an SGX enclave.

Processes only deal with virtual memory (they can indirectly deal with physical memory through abstractions) so it makes no sense to ask about virtual vs physical memory.