Red Team Tactics: Advanced Process Monitoring Techniques in Offensive Operations
In this article, we are going to understand the capabilities of well-known process monitoring utilities and demonstrate how to use the technology underlying these tools for Red Team offensive operations.
A good technical understanding of the system that we rely on is a key criterion for making decisions about what the next step of the operation will be. The collection and analysis of data on running processes in compromised systems gives us a wealth of information and helps us understand how the IT infrastructure of the target organization works. In addition, periodically requested process data helps us respond to environmental changes and receive trigger signals when an investigation begins.
In order to be able to collect detailed data about processes at compromised endpoints, we created a set of tools that brought together the power of advanced process utilities and C2 frameworks (such as Cobalt Strike).
Tools (and their source code) can find here.
Windows Internal System Utilities
To begin with, we will figure out which utilities can be used to collect information about computer processes on Windows. Then we will learn how these utilities collect information so that they can later be used in Red Team toolkits.
The Windows operating system is equipped with many ready-made utilities for administering the system. Although most of the tools provided are suitable for basic system administration, some of them do not have the necessary functions for advanced troubleshooting and monitoring. For example, the Windows task manager gives us basic information about all the processes running in the system, but what if we need more detailed information, such as object descriptors, network connections, or modules loaded as part of a specific process?
To collect such information, there is a more advanced tool. For example, system package utilities Sysinternals. As a Red Team member with extensive experience in network and system administration, I have always been a big fan of Sysinternals.
When troubleshooting a slow-running server system or an infected client computer, I most often started troubleshooting using tools such as Process Explorer or Procmon.
From the point of view of digital forensics, these tools also seem very useful for conducting basic dynamic analysis of malware samples and searching for artifacts in infected systems. So why are these tools so popular among system administrators as well as security professionals? Let’s figure it out, delving into some process information that we can get using the Process Explorer tool.
Using Process Explorer
The first thing we see at startup Process explorer – This is a list / tree of all running processes of the system. This gives us information about the names of processes, their identifiers, the context of the user, and the level of integrity of the process and version information. Additional information can also be reflected by adjusting the columns accordingly.
If we use the bottom panel, we can view all the modules loaded by a particular process, or switch to viewing descriptors in order to get acquainted with all the named descriptor objects that are used by the process:
Browsing the modules can be useful when searching for malicious libraries loaded in the process or for Red Team it is an active security product (for example, EDR) that has implemented an API connection module in user mode.
Switching to viewing descriptors allows you to get acquainted with the type and name of all named objects used in the process. This can be useful to find out which files and registry keys are open, which named pipes are used for interprocess communication.
If you double-click on the process name, a window with more detailed information will appear. Let’s look at some tabs to learn about additional properties of an object:
Tab Image shows information about the binary path, working directory and command line options. In addition, it displays information about the user context, the parent process, the type of image (x86 or x64) and much more.
Tab Threads contains information about running threads in the process. When you select a stream and then click on it, the stack button will reflect the call stack for this particular stream. To view threads / calls launched in kernel mode, Process Explorer uses the kernel driver, which is installed when working in elevated mode.
From the point of view of DFIR, thread information is useful for detecting injections into memory, for example, when there is a threat of file-free viruses. Thus, streams that are not backed by files on the disk can signal suspicious behavior. To get more information about threads and memory, I highly recommend paying attention to the tool. Process hacker.
Another interesting tab in Process Explorer is the TCP / IP tab. On it you will see all the network connections associated with this process. From an attack point of view, this can be useful for understanding when a connection is made from a compromised system. An incoming PowerShell remote session or RDP session may signal that an investigation has already begun.
Using the methods discussed for attack
Now that we have learned a bit of interesting things about processes, and about the information that we can collect about them using Process Explorer, you may wonder how to access this information from our favorite C2 frameworks. Of course, we could use PowerShell, as this would give us the opportunity to use a powerful scripting language and Windows API. However, today PowerShell is under the constant supervision of the security service, so we try to avoid this method.
IN Cobalt strike we can use the ps command in the context of beacons. This command displays basic information about the process based on all processes running in the system. In conjunction with a script
@r3dQu1nn ProcessColor, this method is likely to be the best for obtaining process data.
Command output ps useful for quick sorting of running processes, but they do not contain detailed information that would help to better understand the system. To collect more detailed information, we created our own utilities for obtaining information about processes. With their help, we can collect and enrich information obtained from compromised systems.
It is not easy to replicate the functionality and information provided by a tool like Process Explorer. First we need to find out how these tools work under the hood (and in user mode), then we need to understand how to better reflect this information in the console, and not in the graphical interface.
After analyzing the source code, it became clear that many low-level tools for providing system information are largely based on the native API NtQuerySystemInformation. Although the API and its associated structures are not fully documented, this API allows you to collect a lot of information about the Windows system. So using NtQuerySystemInformation as a starting point for collecting information about the processes running in the system, we will use Peb separate processes to collect detailed information about each of them. Using API NtQueryInformationProcess we can read the structure
PROCESS_BASIC_INFORMATIONusing the process descriptor and find
PebBaseAddress. Then we use
NtReadVirtualMemory API for reading structure
RTL_USER_PROCESS_PARAMETERS, which will allow us to find out the parameters
Using these APIs as the foundation of our code, we have written the following tools for obtaining information about processes:
- Psx: shows a detailed list of all processes running on the system.
- Psk: Shows kernel information, including loaded drivers.
- Psc: shows a detailed list of all processes with established TCP connections.
- Psm: Shows detailed information about the module from a specific process identifier (loaded modules or network connections, for example).
- Psh: Displays detailed information about the descriptor of a specific process identifier (for example, object descriptors, network connections).
- Psw: shows the names of the process windows for which the windows are active.
All of these tools are written in C as reflective DLLs and can be reflectively embedded in a spawned process using a C2 framework such as Cobalt Strike (or any other framework that supports reflective DLL injections). For Cobalt Strike, we have added an aggressor script that can be used to load tools using the Cobalt Strike script manager.
Let’s look at each specific tool launched in Cobalt Strike to demonstrate functionality and show what information can be collected with it:
This tool shows a detailed list of all processes running on the system. The output can be compared with the information on the Process Explorer main screen. Psx displays the name of the process, its id, parent PID, creation time and information related to the binary files of the process (architecture, company name, version, etc.). As you can see, it also displays some interesting information from the active kernel of the system, for example, the base address of the kernel, which is useful when operating the kernel (for example, to calculate the offsets of ROP gadgets). All of this information can be gathered from a normal user context (without elevation of privileges).
If we have enough permissions to open the process descriptor, you can read additional information, such as the context of the user and the integrity level of his token. Enumerating PEB and related structures provides information about the image path and command line parameters:
As you may have noticed, we read and display version information from binary process images, for example, company name and description. Knowing the name of the company, you can easily list all the active security products in the system. Using this tool, we compare the names of companies of all active processes with a list of well-known suppliers of security products and display the results:
This tool reflects information about the running kernel, including all loaded driver modules. Like the Psx tool, it also provides a summary of all loaded kernel modules from well-known security products.
This tool uses the same methods to display information about active processes as Psx, except that it displays only processes with an active network connection (IPv4, IPv6 TCP, RDP, ICA):
You can use this tool to get detailed information about a specific process. It will display a list of all modules (DLLs) used by the process and the network connection:
Same as Psm, but instead of loaded modules, shows a list of process descriptors:
Last but not least tool Psw. This tool will show a list of processes with active window handles, those that are open on the user’s desktop, including window headers. This is useful for determining which graphical application interfaces the user opens without having to take screenshots of the desktop:
You may wonder: “And how does all this help us in offensive operations?” After gaining access to a compromised asset, we usually use this information for the following purposes:
- Detect security tools on a compromised asset. Not only by process information, but also by loaded modules.
- Detecting custom hook engines.
- Search for opportunities for maneuvers (through network sessions) and escalation of privileges.
After the first compromise, you can periodically request similar information about the processes and start creating triggers. For example, we automatically enter this information in Redelk. Then you can create alerts about suspicious changes in process information, such as:
- Launch a security audit tool or install a new end-point security product.
- Inbound network connections from the security department through an RDP session or remote PowerShell.
- Opening a handle by another process on one of our malicious artifacts (for example, a file used to preserve presence).
In this article, we showed how tools such as Sysinternals Process Explorer can be used to get detailed information about the processes running on the system, and how this information can help administrators and security professionals troubleshoot and check the system for security problems or performance.
The same information is also relevant and useful for Red Team, which have access to compromised systems during operation. It helps to better understand the system and the IT infrastructure of your goal, and periodic questioning of such a system allows the Red Team to respond to possible changes in the environment (for example, an investigation trigger).
We have replicated some of the functionality provided by tools such as Process Explorer, so we can use the same information in offensive operations. For this, several process monitoring tools have been created that can be used as part of the C2 framework, for example Cobalt Strike. We showed how to use these tools and what information you can use to collect them.
These tools are available on our website. Github page and ready to use as part of Cobalt Strike.