Malware
Proofs of Concept Abusing PowerShell Core
We explored possible strategies attackers can employ when abusing PowerShell Core. These proofs of concept (PoCs) would help in better understanding the common routines and behaviours of possible and future threats that attackers might use.
Threats that abuse PowerShell continue to increase as attackers find ways to abuse it to deliver banking trojans, backdoors, ransomware, and cryptocurrency-mining malware, and, more recently, fileless malware and malicious Windows Management Instrumentation (WMI) entries. Indeed, PowerShell’s flexibility and capabilities make it a potent tool in cybercriminal hands. For instance, it can be abused to facilitate exploits, lateral movement within the compromised network, and persistence.
In January 2018, Microsoft announced the availability of PowerShell Core, a cross-platform and open-source version of PowerShell. While it’s currently under development, it's similarly expected to draw cybercriminal attention since, like PowerShell, it can be abused to breach their way into other platforms apart from Windows.
We explored possible strategies attackers can employ when abusing PowerShell Core. These proofs of concept (PoCs) would help in better understanding — and in turn, detecting and preventing — the common routines and behaviours of possible and future threats that attackers might use. The PoCs we developed using PowerShell Core were conducted on Windows, Linux, and mac OSs. Most of the techniques we applied can be seen from previous threats involving PowerShell-based functionalities, such as the fileless KOVTER and POWMET. The scenarios in our PoCs are also based on the PowerShell function they use.
Note that there are caveats in successfully abusing PowerShell Core. For instance, PowerShell Core is not installed by default on any platform, which means malware creators cannot easily hack or compromise a machine that has no PowerShell Core installed. For Unix and Unix-like operating systems (OSs), the difference in the file system would require hackers to add a line or two to execute any malware. For example, a downloaded ELF file would not be executable, since its attribute needs to be modified in order for it to be executed. PowerShell Core’s functionalities are also under active development, so its security mechanisms against its abuse will also be fine-tuned.
| PowerShell | PowerShell Core | |
| Versions | 1.0 — 5.1 | 6.0 — 6.x |
| Update Policy | Bug fixes and security updates | Feature update, bug fixes, and security updates |
| Platforms | Windows | Multiplatform |
| Launched as | powershell.exe | pwsh.exe (Windows), pwsh (macOS and Linux) |
| Dependency | .NET Framework | .NET Core |
Table: Comparison of PowerShell and PowerShell Core
As noted in the table above, PowerShell Core can be installed in systems running Windows 7 and later OSs, Linux (Kali, Fedora 27/28, Ubuntu, etc.), macOS 10.12+ (Sierra and later OSs), Windows IoT, and Nano Server.
PoCs of malicious activities involving PowerShell Core
Windows: DownloadFile scenario. The infection chain starts with a malicious document attached in a spam email. Once the document’s macro content is enabled, a command line along with a PowerShell Core script runs to download and execute the intended payload.
Figure 1. Infection chain of a possible threat that abuses PowerShell Core’s DownloadFile on Windows OS (top) and a snapshot of a sample PowerShell Core script that uses DownloadFile to retrieve the payload (bottom)
Linux and mac OS: DownloadString scenario. Since Linux and macOS terminals are the same, a threat that abuses PowerShell Core can be executed in both operating systems. Assuming that the arrival of the malware would be via spam email or an exploit, we simply created PowerShell scripts in order to complete the download and execution of the intended final payload. The initial script that was executed via terminal will then download another PowerShell Core script capable of retrieving the final payload and modifying its attribute to “executable”. This is because the downloaded file via terminal or PowerShell Core script in Linux and macOS environments is not executable by default.
Figure 2. Infection chain of a possible threat abusing PowerShell Core’s DownloadString on Linux and macOS
Figure 3. Snapshot of a sample PowerShell Core script that uses DownloadString to retrieve the payload (top), and the downloaded PowerShell script for retrieving and executing the final payload (bottom)
Windows: Abusing MultiPoolMiner and PowerShell Core. PowerShell Core can also be abused along with other legitimate and gray tools. For cryptocurrency mining-related activities, we tested out the open-source project MultiPoolMiner, which requires PowerShell Core to run properly.
When replicating this scenario, we first checked the start.bat file inside the MultiPoolMiner package, which includes default commands and parameters (miner wallet, username, workername, region, currency, etc.). Our closer look reveals that it will execute a command via PowerShell Core (pwsh). If it is not installed on the system, it will download and install PowerShell Core, and proceed with the execution again.
Figure 4. MultiPoolMiner’s Start.bat downloading and executing PowerShell Core
After executing the batch file, it will start checking the system’s specifications and download all its supported miner applications and conduct a benchmark. This is done in order to install the most optimal cryptocurrency miner for the system. Figure 5 shows how the benchmarking and cryptocurrency mining processes are conducted.
Figure 5. MultiPoolMiner’s benchmarking and cryptocurrency mining processes
Best practices
Given the possible impact of PowerShell Core’s abuse, users and businesses should adopt best practices to reduce their exposure to threats that may abuse PowerShell Core:
- Deploy security mechanisms such as behaviour monitoring, which helps detect, monitor, and prevent anomalous and malicious routines and modifications from being fully executed in the system. A good behaviour monitoring system not only blocks malware-related routines; it should also be able to monitor and prevent unusual behaviours, such as when PowerShell Core is invoked via malicious macro embedded in documents.
- Implement defence in depth: Deploying a sandbox provides an additional layer of security by containing malicious scripts and shellcode. Employing firewalls as well as intrusion detection and prevention systems helps deter behaviours like command-and-control (C&C) communications and data exfiltration.
- Apply the latest patches (or employ virtual patching) to prevent vulnerabilities from being exploited.
- Enforce the principle of least privilege: Restrict or secure the use of PowerShell and/or PowerShell Core; disable or remove unnecessary and outdated plug-ins or components to further reduce the system’s attack surface.
This has been presented as “One (S)hell of a Threat: Gateway to Other Platforms” in the AVAR Conference, held on November 28, 2018 in Goa, India.