Malware camouflage: threat through manipulated command lines (InfoGuard Cyber Security Blog) Newsletter

Malware Cloaking: the Growing Threat of Manipulated Command Lines

Many detection mechanisms and investigation techniques focus heavily on analysing the command lines of processes. Increasingly, we are seeing these command lines being modified by malware – see for example the Rohrschach malware or the BlackCat attack pattern. This blog post explores why this is so easy to do, despite all the protective measures.

Windows manages processes in what are known as “_EPROCESS structures”, which contain metadata about processes. The exact structure of these kernel objects can be easily viewed in the Windows Debugger.

Kernel object in the Windows Debugger (_EPROCESS structures)


Kernel objects are separately protected from modification by PatchGuard on all 64-bit Windows systems, so PatchGuard would throw a blue screen and reboot the system if malware structures in _EPROCESS blocks were modified. Yet how is it still possible for malware to modify metadata about a process, in this case the command line?

The answer is that the command line of a process is not managed directly in the _EPROCESS structure, but in what is known as the “Process Environment Block”. This is located in the memory area of the process itself. Write permissions exist for this area, which additionally are not monitored by PatchGuard.

How to find and modify command lines 

A practical example shows where the command lines of the processes are located and how easily they can be modified. I will try to describe the procedure in such a way that you, as an interested reader, can perform the experiment yourself. All you need is for a Windows Debugger to be installed. You then attach this Debugger to the Windows core via the “Open” dialog.

The first step is to launch a process whose command line is to be modified. To do this, we open PowerShell. This is because we will be using a PowerShell script that is also used by attackers who are believed to be associated with the BlackCat ransomware.

We also open the Task Manager and make the command line column visible.


Verwendung eines PowerShell Script: Kommandozeilen finden im Task Manager


We now use Windows Debugger to locate the _PEB of the Powershell process.


Using a PowerShell Script: Windows Debugger to locate the _PEB of the Powershell process


Conveniently, the Windows Debugger provides direct links to important structures such as the _PEB. A simple click will obtain a summary of the objects of interest referenced in the _PEB. It is important here that the context of the process is entered (red box) to display the _PEB before the _PEB is called. This shows that we have now moved away from the memory area monitored by PatchGuard. 


Windows Debugger offers direct link to structures like the _PEB


To de-reference the _PEB cleanly, we now click the blue address by the text “PEB at”. 


_PEB dereference via blue address


The command line is not linked directly under the _PEB, but managed in a structure called ProcessParameters of the type RTL_USER_PROCESS_PARAMETERS. A simple click lets us take a closer look at this structure.


Command line within the Process parameter


As already touched on, the references to two Unicode buffers containing the ImagePathName and the CommandLine of the process are located here. Clicking the blue CommandLine link followed immediately by the “Raw View” link describes this buffer in more detail.


Two Unicode buffers, they contain the PathName and the CommandLine

Exact description of the Unicode Buffer


So, in the illustrated example, the actual buffer is located at address 0x219022c256c in the virtual memory of the PowerShell process. Another way of trying this is to decode the data at this memory address as Unicode.


The buffer is shown in the virtual PowerShell process


Intuitively, it should now be possible to modify this data. After all, the Windows Debugger runs under system privileges and should have access to all memory. We can use the “eu” command to populate memory areas with Unicode.


Using the eu command to fill memory areas with Unicode


Unfortunately, we get an error message at this point. I used Windows 10 for this experiment, which includes measures that prevent a simple modification of the _PEB. However, the reason for this is not down to security, but to avoid parallel access to the data structure by various other programs and the Windows core, which could otherwise lead to deadlocks. After all, the _PEB is also home to frequently changed variables such as the current working directory. So how does malware still manage to modify this data?

The answer is quite simple: whenever the _PEB is to be written, write protection must be enabled beforehand. This is realised by what is known as a “critical section” called FastPebLock. Thus, if a thread wants to write to the _PEB, exclusive write access must be established via the FastPebLock structure beforehand. For example, the Windows API provides the function “RtlEnterCriticalSection” for this purpose.



Thus, if malware wants to modify the _PEB, the lock must be established as a priority. Now let’s have a look at the Masquerade-PEB.ps1 script. This allows the command line of the PowerShell process in which it is called to be changed to any value.


Command line from the PowerSehll process, is changed as desired


It is clear in the code that the PEB lock is obtained before any changes can occur.


The PEB lock is pulled, thus preventing changes


Now we can easily test the script by fully loading it into the PowerShell window. The command line can then be modified.


Testing the script by loading it into the PowerShell window


Launching the task manager again shows that the command line of the PowerShell process has indeed been modified.


When restarting the task manager, the changed command line is visible


The bottom line – don’t forget Windows Debugger

During both monitoring and investigations, it must always be clear which process parameters are easy to modify and which are difficult. For SOC analysts and incident responders, it is definitely worth opening the Windows Debugger every now and then to better understand memory and the Windows core.

Would you like more technical insights as well as tips from me and my team? Subscribe easily to our blog updates and never miss an article!Subscribe to our Blog Updates now!

<< >>

Cyber Risks , CSIRT

Mathias Fuchs
About the author / Mathias Fuchs

InfoGuard AG - Mathias Fuchs, Vice President Investigation & Intelligence

More articles from Mathias Fuchs

Related articles
Ransomware attacks becoming more and more professional – and dangerous
Ransomware attacks becoming more and more professional – and dangerous

The fact that ransomware attacks are taking place is now widely acknowledged, but even so, the attacks are [...]
Cyber Threat Intelligence Insights: Timing of Ransomware Incidents
Cyber Threat Intelligence Insights: Timing of Ransomware Incidents

In the last blog post, we looked at the 53 largest CSIRT cases in 2022. In this post, we will focus [...]
Ransomware – a Latent Threat [Part 1]
Ransomware – a Latent Threat [Part 1]

For a long time now, ransomware has been an issue, but it's far from being a short-lived phenomenon – quite [...]

Exciting articles, the latest news and tips & tricks from our experts on all aspects of Cyber Security & Defence.

Blog update subscription
Social Media