First of all, we need to clarify the current situation in the field itself. The news is full of malware statements that were using PowerShell. Antivirus companies are describing that there is a decent amount of PowerShell usage within malware, and each day new vulnerabilities are being disclosed. In addition, we saw drastic impacts, with ransomware compromising whole companies and even hospitals by encrypting thousands of machines. We have many security conferences in the world: BlackHat, Def Con, Troopers, BlueHat, and BSides, to name a few. At all of these conferences, we can see demos that make use of PowerShell and demonstrate some attacking or exploiting techniques using it. This is only the tip of the iceberg, as we see also an increased use of PowerShell tactics in the lateral account movement. On GitHub, you can download many pentesting frameworks that are implemented with PowerShell. They have different uses such as post-exploitation, reconnaissance, and so on.

The result of all these ongoing actions is that most customers—especially the top management—thinks that PowerShell is a vulnerability and needs to be shut down. Even you might think like this, but in this topic we are going to add the technical facts behind these feelings. The public is quickly forming their opinion, even without having dedicated facts. In the past few years, we have been confronted with many of these public feelings and to demonstrate to you what the current situation in the field looks like, here are some commonly heard quotes:

• We used ExecutionPolicy to shut PowerShell down. Nothing should happen anymore.
• We disabled PowerShell due to Ransomware.
• That's why we use VBS.
• It is unsecure – you can read it in the news!
• The CIO went to a security conference and then banned PowerShell from the environment.
• It's too complicated to set everything up. Therefore, we postponed it for now.
• But whitelisting is hard! It means that you need to know where all of your scripts are!
• We actually don't know who uses PowerShell in our company.
• We have set up logging and analysis. But now we are getting a freakin' high number of incidents!
• Is it possible to uninstall PowerShell?

Though you might have laughed at some of these, they actually demonstrate a devastating problem. The knowledge of PowerShell security has not been shared too much in the past and it is very rare to see a customer who has defined a good baseline. And a good baseline doesn't only consist of the configuration of the ExecutionPolicy.

The dilemma is as follows:

From a defender's perspective, there are many technical security controls available which should consist of the following three categories:

• Detection
• Respond
• Prevention

In the past, defenders tried to build a big wall around their network, defining only one perimeter by default and completely focusing on prevention. The bigger the wall, the more secure you are. If you are still thinking like this, you should change your mind now. There are studies available that calculate the costs for a hacker group to compromise an enterprise environment at around one million US$ (which is not much). In addition, we see increasing costs due to cyber attacks and cyber threats over the last years.

It takes on average more than 80 days to identify hackers in your environment, and attackers start using automation and artificial intelligence in their attack vectors. They need only to find one weakness, instead of defending against all vectors.

On top of that, there are also studies available that recognize that more than half of all attacks are initiated from the internal network (by your own employees).

All these facts are very often stated together with the following quote:

To understand this quote, take a look at your traditional defense mechanisms:

• Roles and rights management: Stored as lists 
• Antivirus definition files: Similar to lists with some heuristic
• Firewall rules: Number of listed rules

In comparison to the view from the defending side, you have attackers that retrieve a lot of information and make use of it in their post-exploitation approach, as well as in the lateral movement in a dedicated and structured way. Take a look at the Bloodhound framework, which, very simplified, just retrieves all the data from Active Directory and visualizes it in a graph.

Today, you should always assume that there already has been a breach and adopt an Assume Breach mindset. This means that you are definitely going to be hacked, it is just a matter of time, and you need to be prepared to react quickly. Therefore, it is important to have incident response processes defined and building up many perimeters, separating user and computer groups into different categories. Microsoft uses the tier-leveling model with the red forest approach for this. And you will also try to use heuristics and graph capable defending mechanisms such as Advanced Threat Analytics. 

This results in a varied list of technical security controls, which may have some technical dependencies and need to be installed or configured to enable more technical security controls. Technical security controls can be integrated into the OS itself, they may come with the PowerShell version, or they maybe part of dedicated servers or network parts, and may even be configurations and policies defined for users or machines. For didactic purposes, we are going to start with the most important technical security controls first. Unfortunately, the number of technical security controls and their dependencies is very high today; we will provide you guidance for most of them and show, at the very end, an approach for creating your own roadmaps.