Fairly recently, my team found ourselves with Remote Desktop Protocol (RDP) connections into a network as a low level user. It was a good spot to be right off the bat, since it was a reliable foothold in the network, but when I said it was a low level user I mean LOW.
The environment we found ourselves in had a lot of security restrictions in place. There was no access to any files outside the user libraries via the file explorer.
We could not open a command prompt or a PowerShell window through the start menu.
We couldn't even use "run."
It seemed like everything was fairly well locked down, but it wasn't time to give up. If there is one thing Windows gives us a lot of, its options.
So without even the permissions to right click(!?!), we set off to find a way to move forward, and before long we had three different ways to open PowerShell and keep testing. With the help of some handy tools like BloodHound and Rubeus and our gained PowerShell access, it wasn't long until we were Domain Admin.
Method #1: Drop a .bat
Hey, you want to know a secret? Internet Explorer is still around, and in a big way.
Want to know another secret? Internet Explorer will run batch files for you.
The process is fairly simple. Especially if your goals are small - like opening a command prompt.
- Open a notepad document. I'd be surprised if your organization didn't allow that.
- Type in "powershell.exe"
- Save it as a batch file to your Desktop.
- Open an Internet Explorer window.
- Drag the batch file into the Internet Explorer window.
- Click through all the prompts.
Method #2: Excel Macros
In an office environment, you probably have access to Excel, which makes this method pretty handy in most situations. Macros are not new, and the security risks associated with them are well documented, so usually an organization will disable them.
That was not this case in this test (it will not be the case in every test) so it pays to have a quick macro handy. Let's walk through how to set it up.
- Enable the Developer tab on the Excel ribbon.
- Open the new macro dialog.
- Name your macro and click "Create."
- Enter your macro script.
- Save the macro.
- Run the macro.
- Grab shell bro.
Method #3: Dynamic Data Exchange
If you read the previous Living Off the Land post I wrote, you'll probably already know this method as a way to get shells through an Excel email attachment. But if you are already in the target network, have Excel, and macros are disabled (rendering method 2 useless), this is a useful way to bring up a local shell as well.
- Open a normal blank Excel workbook.
- Enter the DDE payload into a cell.
- Hit enter and click through prompts.
- Hey look! Another shell.
How Do You Stop This?
So of course it's important to note that this can be secured. In all of these cases you will essentially have a powershell process running with a parent in Internet Explorer or Excel, and frankly, that should "never" happen (I know never say never). The best way to identify this is to monitor for programs running from parent processes that make no sense. Then block it.
That's Hardly All
That's just three ways to bypass restrictions on shells in a Windows environment - it's hardly an exhaustive list. But really, you only ever need one. Play around on your own machine and see if you can find more ways to open applications that you never dreamed existed. You'll be surprised what you find.