Articles written by Adlumin’s Threat Research Team on emerging threats, industry stats, and defense tactics against cyberattacks.

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.

Beauty Is in the Eye of the Deceiver: Deception Technology for Your Zero-Trust Arsenal

Event details:

Thursday, March 16, 2023
On-Demand Webinar

Presenters:

Mark Sangster, Chief of Strategy at Adlumin
Kevin O’Connor, Director of Threat Research at Adlumin

About this talk:

Traditional security measures are no longer enough to keep up with the increase in sophisticated cyber threats. Join Adlumin’s experts in discussing zero trust and complementing detection and response capabilities with deception technology. Deception provides not only early-warning detection but insight into criminal tactics and techniques. This threat intelligence is critical to protecting your business.

What you will learn:

  • An understanding of how zero trust applies to cyber risk management
  • How to use deception technologies to detect threats quickly and gain threat intelligence into criminal tactics and techniques
  • Ways to complement detection and response capabilities with deception technologies to strengthen your security posture


Learning from Your Adversary: An Inside Analysis of the Latest Cyber Threats

Event details:

Thursday, April 20, 2023
1:00 PM EST

Presenters:

Mark Sangster, Chief of Strategy at Adlumin
Kevin O’Connor, Director of Threat Research at Adlumin

About this talk:

Understanding which industries criminals target, how they exploit their victims, and why they prefer these organizations is key to protecting your business or operations. Join Adlumin experts as they look inside the latest threats, criminal tactics, and techniques and reverse engineer defensive measures organizations can take to protect themselves from top-tier ransomware gangs and state-sponsored hackers.

To Catch a Cybercriminal: Honeypot Usage Considerations and Benefits

By: Kevin O’Connor, Director of Threat Research

We returned to the basics in our most recent blog, Honeypots 101: Origin, Services, and Types covering the evolution of honeypots, how organizations are deploying them, and the different types that can help lure away cybercriminals from key assets. Deception tools, like honeypots, add another layer of defense to protect your system while drawing attackers away from where you don’t want them.

We are diving deeper into usage considerations and why deception technology expands security defenses.

Business and IT Systems Benefits

Honeypots are beneficial inclusions in an IT System’s Security Plan for many reasons, including[1]:

  1. Early warning and detection of attacks: Honeypots can detect attacks before they reach critical systems allowing security personnel to respond quickly and minimize damage.
  2. Intelligence gathering and analysis of attack methods: By observing attackers’ behavior on a honeypot, businesses can gain insight into attackers’ methods and techniques to compromise the system. They can provide valuable information about the TTPs used by attackers, which can be used to develop more effective security measures and assist in incident response.
  3. Detecting new threats: Honeypots can detect new and emerging threats as attackers leverage new TTPs, which the honeypot may observe in detail.
  4. Improving security posture and reducing risk: Honeypots can improve an organization’s security posture by better understanding the TTPs used by attackers and developing more effective security solutions. Luring attacks on a decoy system can help reduce the risk of an actual attack on the organization’s networks and systems.

Honeypots can also be used to help meet industry-specific compliance requirements. For example, the Payment Card Industry Data Security Standard (PCI DSS) requires merchants who accept, process, store or transmit credit card information to implement security measures to protect sensitive purchase-related data. While honeypots are not explicitly mentioned by PCI DSS or any other compliance requirements, Adlumin tracks, they can be used as part of a comprehensive and broader security strategy to detect and respond to security threats.

Similarly, the Health Insurance Portability and Accountability Act (HIPAA) requires that healthcare organizations implement administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronically protected health information (ePHI). Again, while honeypots are not explicitly mentioned in HIPAA, they can be used as part of a comprehensive security strategy to detect and respond to security threats to ePHI.

Honeypot Usage and Deployment Considerations

When deciding as an organization to implement and use honeypots as part of a layered security defense, some key considerations can help ensure the honeypot is safe and effective[2].

  1. Placement – a honeypot’s placement is critical to its effectiveness. Honeypots must be strategically positioned within the network to offer potential attackers a target while appearing as legitimate services. Placement also needs to consider the network space in which you are allowing the attacker to gain a foothold. Additionally, decisions to deploy the honeypot on external vs. internal facing infrastructure will determine the types, frequency, and severity of detected attacks. External-facing honeypots are subject to frequent scanning, rogue exploitation by botnets, and attacks of convenience by many different threat actors. This can increase the noise in the logging signals and make it hard to separate real and targeted threats.
  2. Isolation – the honeypot should be isolated from the rest of the network and not contain any sensitive information. This minimizes the attacker’s risk of leveraging access to the honeypots to continue their attack throughout the network using the honeypot as an initial foothold. Honeypot configurations must ensure the attacker is trapped and actions monitored appropriately.
  3. Monitoring – the honeypot should be monitored closely to gather information about the attacker’s TTPs which can be fed into the network and security defenses. It’s not enough to just deploy a honeypot – the honeypot’s logs must be analyzed and used to create detections for malicious activity to warn the organization of potential attacks.
  4. Management & Maintenance– the honeypot should be managed by experienced security personnel who can effectively configure, monitor, and maintain it to ensure its effectiveness in detecting and responding to attacks. Additionally, the honeypot should be regularly updated to ensure that it continues to mimic real-world systems and applications and remain attractive to attackers.
  5. Integration with other Security Measures – the honeypot should be integrated with other security measures such as firewalls, intrusion detection systems, incident response plans, SIEMs, MDRs, and detection alert management, investigation, and response systems. This ensures that the honeypot contributes to the network’s security and helps increase its value by generating detections and alerts to activity. Some honeypots can be used to build detections dynamically based on attacker compromise.
  6. Legal Considerations – the legal implications of using a honeypot must be considered, as some countries have strict laws regarding the monitoring and interception of communications. Organizations should comply with relevant laws and regulations when using a honeypot. There is also the potential to attract and trap innocent users, which should be carefully considered before deploying a honeypot.

Honeypots and Zero Trust

Zero Trust is a cybersecurity approach that assumes all network traffic is untrusted and consequently subject to strict security controls and monitoring. The Zero Trust model assumes that every user, device, and application is a potential threat and should be verified and authenticated before being granted access to sensitive data or systems.

In a Zero Trust model, network access is never automatically granted, even if a user or device is within the network’s perimeter. Instead, all access requirements are subject to multi-factor authentication (MFA) and monitored for suspicious activity. The Zero Trust approach protects against various threats, including malware, phishing attacks, and unauthorized access. By verifying and monitoring all network traffic, organizations can more expediently detect and respond to security incidents, reducing the risk of data breaches and more severe attacks.

Zero Trust and honeypots are security measures used to protect against security threats. While Zero Trust focuses on identity verification and attestation of all users, devices, and applications before allowing access to sensitive data and systems, honeypots detect unauthorized access to sensitive data by creating decoy targets that appear valuable and vulnerable to attackers.

Honeypots can be part of a multi-layered, defense-in-depth security strategy to detect threats to the organization and its networks. If a honeypot is accessed, it can trigger an alert which can be used to investigate potential incidents which complement other Zero Trust security measures such as MFA, continuous monitoring, and network segmentation. Honeypots can highlight where Zero Trust measures have failed and provide early warning against attacker operations and compromise.

Expand Your Security Defenses

The evolution of honeypots is a testament to the creativity and ingenuity of cybersecurity professionals and their commitment to staying ahead of the ever-evolving threat landscape. Honeypots can provide deep insight into attackers’ methods and motivations. However, thought needs to be given to what type of honeypot is best for an organization, what services should be simulated, and how to maximize value through proper deployment and usage.

Visit the Adlumin for Honeypots resource page for more information on expanding your defenses with deception technology.

References

  1. Andress, J., & Andress, J. (2015). Chapter 10 – Network Security. In The Basics of Information Security: Understanding the fundamentals of infosec in theory and Practice (pp. 151–169). essay, Syngress.
  2. Sanders, C., Randall, L., Smith, J., & Sanders, C. (2014). Chapter 12 – Using Canary Honeypots for Detection. In Applied Network Security Monitoring: Using Open Source Tools (pp. 317–338). essay, Syngress, an imprint of Elsevier.