Investigating Powercat Reverse Shell Activity
OVERVIEW
The primary objective of adversaries or attackers is to maintain persistence within the targeted infrastructure. To achieve successful persistence, they often focus on executing various scripts or commands on the compromised system, ensuring they can retain long-term access and control.
There are various tools and techniques attackers use to maintain stable persistence, one of which is Powercat. Powercat is a PowerShell-based networking tool that replicates the functionality of the popular Netcat utility, but is built entirely in native PowerShell. Powercat supports both the persistence and execution phases, enabling attackers to maintain consistent access and execute various commands. This functionality aids adversaries in evading defenses or performing lateral movement across the compromised infrastructure.
For a clearer understanding of how attackers use Powercat to set up reverse shells, refer to the link for internal assessments.
Before diving into investigation and detection, it’s recommended to understand the basic features and characteristics of Powercat. Powercat is a powerful tool for creating bind and reverse shells, and it includes features such as:
- Listening for connections
- Connecting to a listener
- Transferring data over DNS or UDP
- Generating and encoding payloads
- Performing traffic relay
Its primary goal is to establish a connection via either a bind or reverse shell using various techniques. This tool is predominantly used on Windows machines, leveraging PowerShell for its execution.
Investigation Mind-Map
Based on the information provided, we can gain a comprehensive understanding of how Powercat operates, which will assist in our investigation and analysis.
Our main focus should be on investigating both PowerShell logs and network logs. By default, PowerShell generates Windows Event Logs, while network logs are collected according to enterprise settings. As part of our monitoring strategy, we utilize a SIEM system to oversee the host machine and execute various ELK SIEM search queries to identify and pinpoint Powercat activity.
Investigation
Our initial investigation starts by prioritizing and examining logs related to Windows PowerShell, specifically focusing on Event ID 4103 and payloads involving Invoke-WebRequest.
data.win.system.providerName: Microsoft-Windows-PowerShell and data.win.system.eventID: 4103 and data.win.eventdata.payload : *Invoke-WebRequest*
As mentioned earlier, default Windows Event Logs are generated by PowerShell activity. We can query these logs to focus specifically on Event ID 4103, which is associated with PowerShell Script Block Logging in Windows Event Viewer. This event provides detailed information about the commands and scripts executed in PowerShell, making it crucial for monitoring and detecting malicious activities like PowerShell-based attacks. Additionally, by filtering activities related to Invoke-WebRequest, we can identify attempts where adversaries or attackers query web requests to download payloads or malicious files onto the targeted victim. Prioritizing these specific logs helps in focusing on potentially malicious activities.
Monitoring the import of modules is also highly recommended. After adversaries download malicious tools, they often import these modules into the compromised host to carry out various offensive activities.
data.win.system.providerName: Microsoft-Windows-PowerShell and data.win.system.eventID: 4103 and data.win.eventdata.payload : *Import-Module*
By applying the above query, you will obtain results that help identify which specific modules have been imported onto the host machine.
Activities related to bind or reverse shells predominantly involve network activity. When a network connection is initiated from PowerShell, it often involves the System.Net.Sockets.TcpClient module, which is responsible for establishing and managing the connection. By executing the following query, we can retrieve activities associated with network connectivity originating from PowerShell.
data.win.system.providerName: Microsoft-Windows-PowerShell and data.win.system.eventID: 4103 and data.win.eventdata.payload : *System.Net.Sockets.TcpClient*
The query may return multiple results, so it is recommended to review these logs thoroughly. If an external network connection is initiated from PowerShell, the information can be easily retrieved from the results of the query.
By correlating the identified time with network logs, we can determine and identify remote IP addresses associated with the malicious activity.
Unless the traffic is encrypted, it can be easily analyzed to understand the commands executed during a bind or reverse shell.
Alternatively, you can investigate by reviewing the PowerShell command execution history of the infected host machine by running the following command:
cat (Get-PSReadlineOption).HistorySavePath
Investigation can be conducted by reviewing PowerShell logs or, alternatively, by analyzing network traffic. During the network-based investigation phase, one challenge is preprocessing TCP logs, as stable shells are typically established over stable TCP communication. Additionally, it is crucial to filter out abnormal port activity. Monitoring services running on uncommon ports, which are not part of normal network activity, can be particularly challenging in an enterprise infrastructure.
In conclusion, effective investigation of potential malicious activity involving PowerShell and network traffic requires a multifaceted approach. By analyzing PowerShell logs, particularly those related to Event ID 4103, and scrutinizing network traffic for unusual connections or port activity, you can identify and understand potentially malicious behavior. Key steps include monitoring module imports, examining network connectivity through tools like System.Net.Sockets.TcpClient, and filtering out abnormal port activity. Addressing these challenges involves correlating network logs with PowerShell execution history and preprocessing TCP logs to detect stable connections. Comprehensive monitoring and analysis are essential for detecting and mitigating persistent threats within an enterprise infrastructure.
