Our Trovent Security Research Team developed its own ETW tracing tool. We’ll explain how YAETWi makes life easier for malware analysts and pentesting experts.
Reasons for developing our own ETW tracing tool
As a security analyst, you may be working on developing detection rules for a specific malicious application or process using Windows logs and protocols. However, in practice it is often quite cumbersome to correlate the process with the correct logs produced by the operating system – especially when dealing with a remote process.
In addition, the standard tools only go so far. Standard Windows logs have substantial limitations: Not only can they be missing important information that would allow a particular process to be detected, but frequently also lack the details that are relevant for the purpose of detecting (and reducing) false positives.
In reality, when it comes to reducing false positives, the analysis approach with standard Windows logs is no longer an option. So we came to the conclusion that we could do better. We decided to develop a solution that could help us to simplify and speed up the malware detection process.
YAETWi – made and shared by Trovent Security
Our Trovent Security Research Team has developed an open source tool by the name of YAETWi. It makes use of the ETW interface and provides comprehensive tracing capabilities that helps the malware analyst or pentester to delve into the processes to be analysed in both the user and kernel space. Most importantly, it enables easily correlating those processes (both local and remote) with the relevant system events.
Furthermore, we have developed a supporting tool called YAETWix. Its primary purpose is to help the security / malware analyst to easily manage any local process to be analysed.
YAETWix enables:
starting processes in suspended mode to identify their PID;
passing the PID as a parameter to YAETWi.exe; and
continuing process execution, letting YAETWi do the rest of the work by correlating the process (PID) with the relevant OS events.
Correlation of processes and system events: severe limitations!
Performing malware analysis for the purpose of defining detection rules can be a difficult and time consuming procedure, as the correlation between the process to be analysed and the logs is performed on the basis of very sparse information artefacts. These are:
Timestamp – which needs to be manually correlated with the system logs
PID (process ID) – which is frequently difficult to detect for short-lived processes
External IP address – as an indicator for external connections, which is not always easy to correlate with the process to be analysed
Timestamps are generally a good indicator, but the need to manually correlate these with system logs is challenge. Not only does manual correlating slow down the whole process, but the amount of logs generated per second in a noisy environment can significantly affect the process – or make it near impossible.
A process ID is another telltale indicator, however it is quite difficult to detect for short-lived processes without applying some mechanism for suspending the process at startup.
When it comes to external connections, an external IP address can be a valuable indicator. However, most connections in Windows are managed by the svchost service. This makes it very difficult to rely on the process ID alone to trace the execution of a particular command from the outside, as the svchost process can be used by other processes as well.
Improved tracing and detection with YAETWi
Due to the limitations described above, the Trovent Security Research Team decided to develop its own tracing tool. Using the ETW API, YAETWi provides a time-saving, productivity enhancing and reliable approach for analysing the behaviour of malicious processes.
YAETWi provides a slim interface and is easy to use, providing the malware analyst or pentesting expert with as much information as required to subsequently define effective detection rules for malicious processes and their related IOCs.
How does it work?
By specifying an external IP as a parameter, the YAETWi application will start listening on external connections originating from the specified IP, and start logging events for the specific PID(s) assigned to the connection(s).
As explained above, most external connections are delegated to svchost.exe and its shared resources. Therefore the correlation of processes and system events is extremely difficult. But, by using the ETW interface and leveraging the output of uncommon ETW providers, we are able to have an in-depth look at events in the kernel and user space for the purpose of identifying the telltale indicators of malicious processes.
Detection of Impacket Attacks
In the following examples, we describe some practical use cases of improved process tracing with YAETWi by analysing a selection of tools from the well-known Impacket suite – which is popular both with security researchers and malicious actors:
rpd_check.py
wmiexec.py
getArch.py
Detecting rdp_check.py
The Impacket Suite’s rdp_check.py is a tool commonly used by attackers. It enables checking if certain credentials are valid for an RDP service.
In order to understand rdp_check’s behaviour at a granular level, we used YAETWi to trace processes that are triggered by rdp_check.py on the affected host.
What we did:
From the Kali Linux terminal we executed rdp_check.py with dummy credentials against the target host (screenshot 1)
In the PowerShell window our YAETWi tool was started in advance to listen on the incoming connections from the Kali Linux’s IP address (screenshot 1)
After running rdp_check.py, the connection was automatically detected and YAETWi started collecting the ETW events triggered by the PID 788 assigned to the svchost service on the RDP (3389/tcp) connection made by rdp_check.py (screenshot 1)
Using keystroke command ‘d’ we were able to analyse which ETW events were triggered for PID 788 (screenshot 1)
With keystroke command ‘r’ and entering the ETW provider’s name we were subsequently able to perform an in-depth analysis of the events associated with the ETW provider Microsoft-Windows-RemoteDesktopServices-RdpCoreTS (screenshot 2)
(1) An external connection is detected by YAETWi and tracing of the assigned PID is started
(2) A pattern can be identified in the output from ETW provider Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Detecting wmiexec.py
The Impacket Suite’s wmiexec.py is another attacker’s “favourite” often encountered in the wild.
wmiexec.py provides an attacker with a semi-interactive shell using a similar approach to smbexec, but by executing commands through Windows Management Instrumentation (WMI).
As in the previous section, in order to understand wmiexec.py’s behaviour at a granular level, we used YAETWi to trace processes that are triggered by wmiexec.py on the affected host. What we did:
From the Kali Linux terminal we executed wmixec.py (screenshot 1)
In the PowerShell window our YAETWi tool was started in advance and was able to detect some connections associated with the attack (screenshot 1)
Using keystroke command ‘d’ we listed all ETW providers associated with the PIDs (screenshot 1)
By entering keystroke command ‘r’ and the ETW provider’s name, we were able to observe the attack’s pattern (screenshot 2), i.e. the events associated with the ETW provider Microsoft-Windows-WMI-Activity
(1) Three connections are detected by YAETWi and three different PIDs are assigned accordingly.
(2) A pattern can be identified in the output from ETW provider Microsoft-Windows-WMI-Activity
Detecting getArch.py
getArch.py is a another Impacket tool which is frequently used by attackers and offensive security experts.
What is it used for? getArch.py enables the enumeration of the targeted system / environment and would typically be used in the reconnaissance phase of the cyber kill chain.
The getArch.py script connects to the target system over the DCE RPC protocol in order to gather the OS architecture type. This information can be used by an attacker to prepare suitable malware for the target system.
We consider getArch.py to have a very small footprint. In other words, it will often fly under the radar of standard detection mechanisms, because of its use of information provided in the RPC headers. Generally speaking, this makes the use of getArch.py hard to detect.
The following screenshots illustrates how getArch.py is used to identify the target system’s underlying architecture:
Target system architecture information is contained in one of the RPC headers
Shortcomings of default Windows logs for analysis and detection purposes
If we were to rely on default Windows logs, we would only see a single event logged in the security logs with general information about the external connection. This is far from enough to start any kind of detection.
A logged event for getArch.py in the standard security logs
Improved visibility and detection with Trovent’s YAETWi
As for the other Impacket tools (rdp_check.py, wmiexec.py), we used YAETWi to analyse and understand getArch.py’s behaviour at a granular level, i.e. to trace processes that are triggered by getArch.py on the target system. Our objective was to prove that we could use YAETWi to effectively detect relevant processes and system events – event for a malicious tool with such a small footprint!
What we did:
Run getArch.py from the Kali Linux terminal
In the PowerShell window our YAETWi tool was started in advance and was able to detect the external connection by assigning it to the svchost service with the PID 920
With keystroke command ‘d’ we were able to dump all ETW providers associated with this PID
Finally, with keystroke command ‘r’ and entering the name of the ETW provider Microsoft-Windows-RPC, we were able to dump events associated with this provider and PID 920
The end result is that using YAETWi we can detect an ETW provider called Microsoft-Windows-RPC and we can observe that an RPC connection is started and closed within one second. This is exactly the level of visibility and insight required to be able to develop effective detection capabilities!
Observing getArch.py’s behaviour using YAETWi
Starting local processes in suspended mode
There is still a challenge in analysing local processes: After starting a local process, its PID should be passed to YAETWi or any other debugging tool to enable detection. However, the analysis process should be started from the very beginning to make the detection complete, and not after the analysed process has already started.
One way of managing to suspend processes with standard Windows tools, would be to start a process with a debugger such as WinDBG. However, this can be very time consuming.
At Trovent, our security research team felt that we could do better. So we decided to develop YAETWix as a supporting tool. YAETWix allows starting any process in suspended mode by triggering unmanaged code, retrieving its PID, and continuing its execution, after the retrieved PID has been passed to YAETWi as a parameter.
YAETWix makes life easier for the malware analyst
To illustrate its simplicity, below is a snippet from YAETWix’s source code. Its simple, yet powerful implementation is based on the use of unmanaged code in C# to achieve the main goal of process management on the Windows platform.
YAETWix uses the following functions from the “kernell32.dll” library:
Exactly what we need to fully control the runtime of the application!
YAETWix is also extremely easy to use:
It is given only one argument at startup, the process to analyse, along with its required arguments. After the process is started, it is automatically put into suspend mode and its PID is returned.
This can be passed to YAETWi or any other debugging tool. The process can then be resumed by pressing ‘r’.
Using both YAETWi and YAETWix to analyse and detect Netcat
In the following example we’ll show the tracing of nc64.exe by using both YAETWi and YAETWix. Netcat is a networking utility for reading from and writing to network connections. In a malicious context, it is often used by attackers to create a reverse shell back to the control server, as it is not always detected as a malicious tool by some anti-virus products.
To obtain visibility of the behaviour of nc64.exe at a granular level, i.e. to trace processes that are triggered on the target system, we did the following:
Run netcat utility (nc64.exe) to create a reverse shell back to the Kali Linux machine (10.11.14.3) on port 80
The process was immediately suspended and its PID was returned
The retrieved PID was subsequently used as an argument (/pids=) for YAETWi.exe
After starting YAETWi, the execution of the Netcat process was resumed by using the keystroke command ‘r’.
The following screenshots illustrate the process:
Analysing Netcat reverse shell with YAETWi and YAETWix
Ultimately YAETWi – with the support of YAETWix – allowed us to analyse a local process without much overhead and with just a few extra steps compared to testing an external process. It saves time, does not require the installation of additional tools such as WinDBG, and can even be run as a PowerShell script.
What have we achieved? Improved analysis and detection of malicious processes
In this article we have explained the shortcomings of malware analysis based on a purely manual approach using standard Windows logs. This approach is both time consuming and often very error prone.
These shortcomings drove our decision to develop our own tracing tool. YAETWi makes use of the ETW API and enables in-depth, semi-automated tracing of processes.
By using the YAETWi tool, which automatically activates all ETW providers available on the target system, we were able to:
Perform a thorough analysis of the Impacket suite; and
Correctly correlate external processes with corresponding Windows events.
This provides us with the basis to develop effective and reliable detection rules for our own detection platform: Trovent MDR – Managed Detection and Response. We’ll share details in our next article 😉
What’s next? Impacket Attack Detection with Trovent MDR – Managed Detection and Response
In upcoming releases of this article series, we will examine:
an optimised process for writing detection rules for Impacket tools using Trovent’s own detection platform: Trovent MDR – Managed Detection and Response
how to reduce the volume of false positives by performing deep tracing with YAETWi
Are you looking for an attack detection system or a managed detection & response solution for your organisation? Please schedule a demo session with our team. Or are you looking for pentesting experts? Don’t hesitate to get in touch with us! We would be happy to advised you regarding your requirements.