PowerDrop: A New Insidious PowerShell Script for Command and Control Attacks Targets U.S. Aerospace Defense Industry
Key Takeaways
- The Adlumin Threat Research discovered a new malicious PowerShell script called PowerDrop, targeting the U.S. aerospace industry.
- This novel malware straddles the line between basic a “basic off-the-shelf threat” and tactics used by Advanced Persistent Threat Groups (APTs).
- PowerDrop uses advanced techniques to evade detection such as deception, encoding, and encryption.
- Adlumin has not yet identified the threat actor behind the malware, but suspects nation-state aggressors as the discovery comes at time of increased R&D into missile programs as the war in Ukraine continues.
- Adlumin advises that those in the aerospace defense industry remain vigilant against this new malware. The company recommends running vulnerability scanning at the core of Windows systems and being on the lookout for unusual pinging activity from their networks to the outside.
Introduction
The Adlumin Threat Research Team recently discovered and analyzed a new type of malware targeting the U.S. aerospace defense industry. The discovery comes at a time when more research and investment are put into missile programs as the war in Ukraine continues, and partners around the world remain on high alert.
“PowerDrop” is the name Adlumin researchers have given the malware they found implanted in the network of a domestic aerospace defense contractor in May 2023. The name is derived from the tool, Windows PowerShell, used to concoct the script, and “Drop” from the DROP (DRP) string used in the code for padding.
The threat was detected by Adlumin’s machine learning-based algorithms which analyze PowerShell commands and arguments at run-time.
Upon reverse engineering, Adlumin’s team found that the malware was made up of a new PowerShell and Windows Management Instrumentation (WMI) persisted Remote Access Tool (RAT). The code sends Internet Control Message Protocol (ICMP) echo request messages as a trigger for the malware’s command-and-control (C2), along with similar ICMP ping usage for data exfiltration.
In essence, researchers concluded that the malware is being used to run remote commands against victim networks after gaining initial access, execution, and persistence into servers.
The usage of PowerShell for remote access is not new, nor is WMI-based persistence of PowerShell scripts or ICMP triggering and tunneling, but what is novel about this malware is that another code like it hasn’t surfaced before, and it straddles the line between a basic “off-the-shelf-threat” and the advanced tactics used by Advanced Persistent Threat (APTs) Groups.
Adlumin has not yet identified the threat actor behind the malware, but nation-state aggressors are suspected.
“This latest attack shows the evolution of ‘living off the land’ tactics by threat actors,” said Adlumin’s Vice President of Strategy, Mark Sangster.
“While the core DNA of the threat is not particularly sophisticated, its ability to obfuscate suspicious activity and evade detection by endpoint defenses smacks of more sophisticated threat actors. The fact it targeted an aerospace contractor only confirms the likelihood of nation-state aggressors,” Sangster added.
Kevin O’Connor, who heads Adlumin’s Threat Research Team said that the malware uses triggers and exfil patterns which are easily flagged by intrusion detection systems, but that the malware also appears to be a “custom” development, using advanced techniques to evade detection such as deception, encoding, and encryption.
“Adlumin’s Threat Research Team believes this malware presents a real threat as it has been able to evade detection by some commonly deployed EDR software, likely due to its practice of encoding the PowerShell command line arguments and the use of WMI for persistence,” O’Connor added.
Threat Analysis
Adlumin first identified the PowerDrop malware based on a machine learning detection which looks at the content of executed PowerShell scripts versus the command line arguments typically analyzed by other security software.
“This allowed our detection algorithms to see through the encoded layer enabling machine learning-based detection on the actual content of the script which is acting as a backdoor or RAT,” O’Connor said.
The malware is a PowerShell command that is executed by the WMI service. The “script,” passed as a single command line argument to the native Window’s binary and subsystem. PowerShell is encoded using Base64 and UTF-16 Little Endian and is not persisted on disk as a .ps1 script file.
Sample of Base64 UTF-16LE encoded PowerShell payload:
Execution and Persistence
Adlumin analyzed the PowerShell process execution context to identify that the malicious PowerShell script/implant was being executed by the WMI service using previously registered WMI event filters and consumers.
The WMI event filter and consumer registrations were created by the malware during the initial installation of the PowerDrop implant.
The WMI event filter and consumer registrations are created using the WMI command line tool ‘wmic.exe’ and are executed using the ‘wmic.exe’ command line tool.
PowerDrop registers itself as a WMI event filter and consumer as observed in these Windows Event Logs:
The WMI event filter triggers the PowerShell command queries for updates made to the WMI class Win32_PerfFormattedData_PerfOS_System in the root\cimv2 namespace.
The Win32_PerfFormattedData_PerfOS_System class is the Windows Management Instrumentation (WMI) class that contains performance counters which monitor the performance of the Windows operating system.
The WMI event filter is triggered when the WMI class is updated, which then triggers the execution of the PowerShell script. Triggering by the filter is throttled to once every 120 seconds so long as the WMI class has been updated. In Windows, this WMI class is regularly updated with information such as processes, threads, queue length, and system calls per second, and therefore execution every 120 seconds is reliable and guaranteed on most systems.
WMI filter and consumer registrations for persistence and execution of PowerShell payloads have been seen in many other malware families as has the usage of the PerfOS_System WMI class as a reliable trigger for execution.
The EventFilter and CommandLineEventConsumer are both registered under the name, SystemPowerManager.
The WMI event consumer is a CommandLineEventConsumer which executes the PowerShell command line with the encoded PowerShell script as a command line argument.
We were unable to identify the source of the WMI event filter and consumer registrations, but we believe that the malware is likely using a previously known exploit to gain initial access to the victim’s computer such as a phishing email or drive-by download and execution through wscript.exe and that the command line filter and consumer registrations are created by the malware during the initial installation of the PowerDrop implant through a wmic.exe command line execution.
The Script/Implant
Once decoded the PowerShell script is a single line of PowerShell code made up of multiple statements, functions, and usually static variables.
Analysis of the decoded content shows that the script is a backdoor/RAT, which can execute remote PowerShell commands against the victim computer and exfiltrate the results of those commands.
Initially, PowerDrop attempts to reach out to a hard-coded IP address over an ICMP Echo Request message.
This request is originated by Windows PowerShell and has detectable attributes such as the ICMP Type and Code (8 and 0), the IPv4 Time to Live (TTL) being 128 as natively seen on Windows devices, the ICMP Identification number is set to ‘0x0001’ and the ICMP payload.
The ICMP trigger payload is a UTF16-LE encoded string that is not obfuscated, obscured, or encrypted. Observed examples used the simple string “!” as the trigger for the malware C2 beacon. We believe this simply signifies to the command-and-control infrastructure that this is a malware implant beacon and not a randomly received probe, which are common occurrences against Internet-facing devices.
Once the beacon has been sent, the victim machine waits 60 seconds for a response. This 60-second dwell time is varied from the typical default 10-second request timeout for ICMP Echo Request messages on Windows. This is likely to ensure that the malware can receive a response from the C2 server even if the network is experiencing high latency or packet loss especially given that there is no guaranteed delivery or acknowledgment for the ICMP Echo Request message.
In response to the PowerDrop beacon, the command-and-control server responds with an encrypted payload that is also padded with static data at the beginning and end of the message.
PowerDrop uses AES encryption with a 128-bit key and a 128-bit initialization vector (IV) to encrypt the payload. The AES key and IV are static symmetric keys that are hard coded into the PowerShell script and are not dynamically generated. The AES key and IV are also not obfuscated, obscured, or encrypted beyond the initial PowerShell script encoding.
PowerDrop is using the PowerShell provided interface, “CreatEncryptor” and “TransformFinalBlock” to encrypt and decrypt the payload.
PowerDrop will then receive a response from the C2 server in the form of an encrypted command. The implant will then decrypt the command, strip the prepending and postpending values, and execute the command using the Invoke-Expression cmdlet in PowerShell.
The implant will then take the results of the command and encrypt them using the same scheme used for decryption and send the results back to the C2 server.
Any oversized responses, those greater than 128 bytes, are split into multiple messages. The first message is sent with the first 128 bytes of the response and the subsequent messages are sent with the remaining bytes of the response in 128-bytes chunks. The C2 server is responsible for reassembling the response:
PowerDrop uses the strings “DRP” and “OCD” as prepending and postpending values bookmarking the response content to the C2 server. The prepending and postpending values are used to indicate the start and end of the response content.
If the response is split into multiple messages, then all messages with have the prepending “DRP” value, and only the final message with have both the “DRP” prefix and “ORD” suffix. The prepending and postpending values are not encrypted and are static values in the PowerShell script. Example of the prepending and postpending values:
“PowerDrop’s robust detection evasion characteristics is what makes this interesting,” said Sangster.
“This discovery by the Adlumin Threat Researchers shows that a master chef can make a Michelin-star meal with even the most basic ingredients. Infiltrating a critical aerospace defense contractor only makes this malware all the more appetizing,” he added.
Detections
Adlumin has produced the following detections to help identify potential instances of this malware both on the endpoint and through captured or monitored network traffic.
Snort Detection
This detection can be applied to outbound network traffic and detects instances of PowerDrop malware data exfiltration.
SIGMA
This SIGMA detection identifies PowerShell executions via the PowerShell script block for unencoded and required components of the PowerDrop malware:
Conclusion
Adlumin advises that those in the aerospace defense industry remain vigilant against this new malware that’s making the rounds. The company recommends running vulnerability scanning at the core of Windows systems and being on the lookout for unusual pinging activity from their networks to the outside.
“PowerDrop clearly shows that mixing old tactics with new techniques proves a powerful combination in today’s age,” said Will Ledesma, Director of Adlumin’s Cyber Security Operation Center.
“It highlights the importance of having dedicated 24/7 cybersecurity teams within any operational landscape,” Ledesma added.
