Readers!

From last couple of weeks I have been doing some analysing of malware. Mostly, are via phishing attempts. What our adversaries are doing is to first gain easy access to the machine via phishing and creating background processes that calls the compromised domains that downloads the executable, packed with malicious payload. Below is basic timeline of a phishing email with attachment.

The technique is neither new or unique, however if we are to come up with a trend we can see that most of them have similar tools and procedures.One such tool is PowerShell. The blog is not about what PowerShell is, but how our adversaries are using the tool that was just created to automate admin tasks within Windows environment. As automation is was one of the key points PowerShell was given scripting. The scripting allows to automate admin tasks such as configuration management etc. Here I go explaining what PowerShell is.

Microsoft definitely didn’t intended the tool to be security aware, and therefore till this date one can use PowerShell to perform malicious activities. However, certain controls or functionality within PowerShell can assist us in controlling type of scripts that can run on the systems.

There are indeed multiple security controls that we will discuss later in the blog but first let’s see what our adversaries are doing. I will not be going in specific analysis of a malware as I am trying to reach out to the teams which are responsible to detect/prevent these type of attacks by placing feasible and actionable security controls with regards to PowerShell.

Below is a sample PowerShell command seen in most cases :

Frequently used parameters :

1. ExecutionPolicy bypass – Execution policies  in  PowerShell determines whether a script can run and what type of scripts can run and also sets default policy. Microsoft added a Flag called ‘bypass’, which when used bypasses any currently assigned execution policy and runs the script without any warnings. There are 4 types of Execution policies:
   1. Restricted
   2. Unrestricted
   3. AllSigned
   4. RemoteSigned
2. windowstyle hidden – This parameter is used when PowerShell script requires to be run in background without the users knowledge.
3. noprofile – PowerShell profile are set profile or commands (it is actually a PowerShell script), normally for current user and host. Setting -noprofile will just launch any script and will not look for profiles.
4. DownloadFile – For downloading the file via web

Tools, Technique and Procedures:

1. The attachments as shown in the first screenshot, are mostly Word/Excel doc with Macros or zip files with JavaScripts.
2. The Macros or JS are heavily obfuscated and sometimes lightly. For heavily deobfuscated scripts I rely on dynamic analysis(the best way to know what malware is written for). Some scripts, due to practice, I can deobfuscate within minutes.
3. PowerShell command to download the file are mostly on sites with HTTP rather on HTTPS (there are some sophisticated adversaries created/compromised HTTPS websites). Sometimes, also have noticed use of cmd.exe /c being used which will invoke specified command and terminates it.
4. File on the compromised domain are mostly windows executables with ‘.exe’ or sometimes the extension is hidden. This depends on the adversary and the packers that they have used. Sometimes, you can unpack the ‘exe’ via 7zip.
5. Based on the commands the file will be first downloaded and executed. In certain cases I have seen the file gets deleted after execution. Again, it depends on the command.
6. Most malwares that I have analysed were either ransomware or trying to steal information and sometimes combination of both.

Above TTPs are very simple to understand however, implementing security controls, lets say for each steps to detect and prevent, is much harder. We as a team or individual are working towards reducing the impact of the incident. Consider the phases of cyber kill-chain and perform an analysis of incidents within your team, and understand at which phase you are able to catch the adversary and can you do that earlier?

Observables such as IP addresses, domains, URLs and file hashes with context are the IOCs that normally we look for and use it for detection and prevention. Some people call that Threat Intelligence. Darwin would have gone here Seriously?

Security controls such as Endpoint solutions, Proxy, IDPS and FW can help us but they are heavily dependent on what they know and history has shown us that they can be bypassed. However, they are indeed very good controls to either reduce the impact and/or preventing the known attacks or IOCs.

What we need is security controls based on TTPs. So let’s see some of the following controls that can be implemented to either detect and/or prevent such attacks :

1. DO NOT give admin privileges to the local account. If required based on their role give have a Admin pass generator with User Access Control (UAC) enabled, that will prompt to enter password for Administrator every time a system change such as installing a program, running an Admin task etc is created.
2. Group policies to have certain tasks especially script execution and writing to registry and windows directory only allowed by Administrator. Can use Administrative Templates.
3. Group policy to not allow any executables in TEMP directory to be saved/executed.
4. Sign all PowerShell script. If not possible or the team not willing to sign at restriction placed via above mentioned points can assist.
5. Can also set the Execution Policy to Restricted, PowerShell can only be used interactively to run the script. Organisation who are not pushing any policies via PowerShell can choose this option.
6. Application whitelisting – Windows AppLocker. The tools can assist to define what level of access a user can have on the system with regards to executables, scripts and DLLs.
7. Having AppLocker in Allow Mode can assist the team with a rule that only scripts at trusted location can run on the system. A attacker can re-write the rule provided, he/she has access on the system with Admin privileges.
8. PowerShell Language Mode – Admin can setup the language modes to Constrained Language Mode that permits all Windows cmdlets and all Windows PowerShell language elements, but it limits permitted types. It has list of types that are allowed within a PowerShell script. For example, New-Object type cmdlet can only be used with allowed types which does not contain system.net.webclient.
9. Logging of PowerShell is also important. Here, in my opinion Sysmon is a must have. The logs can be forwarded to SIEM for correlation. If Sysmon is not feasible, enabling PowerShell Module logging is highly recommended. Enhanced logging is always recommended and will  write another blog on that.
10. Organisation proxy to be configured properly to detect/prevent web request invoked via PowerShell. Have tested with command Invoke-request that can show WindowsPowerShell within User-Agent. However, no User-Agent string is noted when above mentioned to DownloadFile is used. May be Proxies can be configured to disallow any traffic without User-Agent – still have to verify whether such functionality exists. If not a SIEM rule can be used to alert on web traffic that has no User-Agent string, going to external sites and downloading files.

Please note, that AppLocker and Powershell constrained mode are not security feature but another layer of defense which can help to reduce the impact of the attack and in some cases completely prevent the execution of foreign scripts.

When making a business case to the board or C-Level executives to make any changes in the organisation the presenter should use language they understand. As part of the evidence it highly recommended to show actually incidents where current security controls failed which impacted the productivity of the user, loss of data and hours spent to recover and restore systems. They want to know how any new mentioned or suggested changes will help in reducing impact to the user or business.

If there are other methods that other organisations are using please let me know.

A good read – PowerShell for Blue Team