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.
Look at the left sidebar. Not even “This PC”
We could not open a command prompt or a PowerShell window through the start menu.
Can you at least give me an “Access Denied” or something?
We couldn’t even use “run.”
Walk don’t run…actually don’t even walk
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.
Thanks w3counter.com
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.
-
…
-
Profit
Oh yeah…..
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.
1. Enable the Developer tab on the Excel ribbon.
File -> Options -> Customize Ribbon
2. Open the new macro dialog.
Developer tab -> Macros
3. Name your macro and click “Create.”
4. Enter your macro script.
Shell “CMD /K powershell.exe”, vbNormalFocus
5. Save the macro.
Save as a macro-enabled workbook
6. Run the macro.
Developer tab -> Macros
7. 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.
It’s like a turtle colony out here.
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.
Bottom line: If you see a powershell running from Internet Explorer, there better be a really good reason for 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.