NFAL: Episode Two (Point 5) – Breaking out of the Jail


I started writing this blog post a long time ago (October 2013 wordpress tells me) and figured it was about time I published it just to clear my decks of “draft” posts as it were. I intend to publish things more often but maybe not all Pentest based, some ham radio and electronics gumpf may filter into it as those are also hobbies of mine.

With that and the slight addition that this was going to be NFAL Episode Two on it’s own so its now kind of NFAL Episode 2.5 The continuing adventures of noddy testing… on with the original post!


Forgive me if this comes across as teaching all 1 of my readers to suck eggs but this is just a dump of common ways I often find useful for breaking out of kiosk jails.If you’re a penetration tester or even a savvy user, chances are you already know of these methods but this is noddy stuff, purely because I thought it made for a fun blogpost, it was fun playing with it on client systems at least.

I did this as a talk at an internal company training day and titled it “Smashing Windows” slides for the talk will be attached at the bottom of the blogpost for what it’s worth but I’ve no recording of it and this blog post is essentially just it regurgitated from memory :)

Recently I did some testing involving the “Remote Application” features of terminal services through a terminal services web gateway.

Initially logging in using AD credentials on the front page you’ll be presented with a few icons on the webpage which in turn launches applications. (Similar to CITRIX stuff i’ve seen in the past). You get presented with a full application as if it is on your desktop, similar in the way VMWare Fusion works on the Mac, its not a full “session” but rather an “application session”.

The beauty with it (at least from our point of view) is that File – Open, will open files on the remote server (providing they haven’t GPO’d paths out of the address bar, etc).

Spawning any processes will spawn them on the remote server and present them to you over terminal services. So if you get an external link to click, it’ll spawn IE which again will be on the remote server.

Another thing to note is that the processes you’re spawning will be on the application server serving that particular application not the web host that is just presenting the applications.

For a recent client I had access to about 6 different applications each one hosted by a pair of load balancing application servers. So breaking the jail on one, got me MSTSC and I just logged in using that into the other application servers/etc that made up the network (having a nice portable portscanner/discovery tool is very useful at this point).

Method #1 – Open Sesame

The File Open and File Save dialogs are king. If you have access to one of these you’ve basically got a mini explorer.exe. There are several avenues of attack.

The File Open dialog box, a veritable feast of juicy jail breaking goodness.
The File Open dialog box, a veritable feast of juicy jail breaking goodness.

The Orange Box – Known as the breadcrumb, this little thing normally is affected by some GPO and is limited in use but can be handy hopping back up the directory structure.

The Yellow Box – Filename box, Unlike the breadcrumb this one appears to be affected by different GPO policies and is not always locked down. I have been able to browse to C:\windows\system32\cmd.exe in here when the breadcrumb wouldn’t let me out of my own profile. Try typing exact paths to existing files and you may find yourself lucky.

The Red Box – Search and Help. Two great ways of breaking out of the jail. Search can often get you files, providing your “high” enough up the tree. Help can find you ways of popping Internet Explorer open. So can search if its unsuccessful finding files, it’ll often prompt you for “search online” which will likely result in IE spawning.

The rest… it’s unlikely you’ll get a nice folder pane on the left hand side, normally you’ll end up with some basic folders available but no ability to browse out of your user profile if its locked down, but its worth a quick look and the file type box, that will limit you when writing a file or saving one. If it has an “all files” option, that’s better.

Finally right click! try it… if you’re lucky you’ll be able to write a file, rename it to .bat or .vbs, get some script running commands for you, its a long shot but hey it might work.

Method Two: IExplore.exe your hard drive

Aside from the usual address bar file://c:\ or browsing to your own metasploit browser autopwn. There are also ways and means of breaking out of this that aren’t so obvious.

File – Open… Or the address bar, IE can open any files. It’s not limited by file filter, it can also open network resources just fine and view folders. Great for accessing hack armoury resources.

Drag and drop… Want to exploit the file “open with” dialog? Drag and drop an unknown file extension onto it and it’ll pop it right up after you hit “open”.

Working on an embedded windows client (*Cough* Embedded XP Wyse Terminals*cough*) and have no access to the file system? That sucks. Try tools – Internet options, open objects and open files will often net you two different drives, the first being the system ram drive, the second being your user profile area.


Finally, have access to the file system but still can’t spawn anything interesting? Try firing up word or any of the office suites, how?… Look for “read me” and licence files.

You may get lucky and find some .doc style terms of service links or be able to create your own .doc. Once you’re in word go for macro execution and you’re winning.

Method 3: If in doubt… give it a clout!

Also consider the windows error reporting dialog, on one particular job I couldn’t access notepad.exe myself and the file open dialog I had access to could only see *.acme files, so was pretty useless.

Help and support was disabled so help got me nothing, however entering in a string instead of a number into an input field of the application would cause the application to crash and the windows error reporting window to pop up from there I viewed the microsoft privacy policy and pow… Internet explorer! which lead me onto bigger and better things 😉

Powerpoint Presentation: Smashing Windows

NFTF: Local Lockdown – Getting prompts, Fun with Macros and Scripting Help on Airgapped Systems

1. NFTF Quickie – VBS Funtimes – Run Scripts? Get Prompt This is probably a duplicate somewhere but wanted it noted for my own use anyway – here’s a very handy VBS that does the job nicely for accessing useful commands as a user on a locked down d…

1. NFTF Quickie – VBS Funtimes – Run Scripts? Get Prompt

This is probably a duplicate somewhere but wanted it noted for my own use anyway – here’s a very handy VBS that does the job nicely for accessing useful commands as a user on a locked down desktop.

Using VBS to fire up FTP as a local command shell

‘Run ftp…
CreateObject(“WScript.Shell”).Run “cmd.exe /k ftp”

Using the above and the bang character will let you run commands on the host.

E.G. !cd or !c:windowssystem32calc.exe (strangely on XP64 !cd will not persist post command, however it does do so on Win7 [pretty sure it does it on 32bit XP as well as it’s how I used to use FTP all the time])

Noddy stuff indeed but useful.

The above one-liner can be modified to run any executable you have access to as a user.

2. No Macros Allowed? That’s what you think…

Me and a colleague got presented with a “Defect fixed, macros are completely disabled on the host” statement on Monday, so we decided to give it a bit of a kicking.

At first glance, no access to the editor was possible and only trusted signed macros were capable of running. We could be forgiven at this point for even mistakenly “passing” the defect if we hadn’t been so determined.

So after a bit of poking and managing to pop open the editor across the office suite, I was convinced I could get it to play ball all the way. My colleague thankfully indulged my inane ramblings about “digitally signing” and “feeling like it’s so close”.

3 to 4 hours later and a fair few dead ends. We get macro editing and execution as a trusted signed macro across all the office apps available on the host (aside from outlook, that could probably fall too given more poking but we had proved the point).

What follows is a quick run through of what we did (…using only a standard user account on a locked down host).

2.1. First Problem – Creating the macro, we need an editor



If the macro menu is disabled and the buttons on the developer toolbar are greyed out (the buttons above are just to show where they are) try the following: 

In Word: Right click the toolbar, select “customise quick access toolbar”, select “all commands” and add the button labelled “view code”.

At this point now go to the developer toolbar (enable it within word options if not enabled), select “design mode” and now the “view code” button will become clickable.

Click this button – Voila, access to VB Editor.

In Excel: Right click the sheet tab, View Code – Voila, access to VB Editor. Alternatively it is also accessible the same way as in word.  

In Powerpoint: Click “view code” (should already be on the toolbar somewhere, if not follow the instructions for word)

The above all work in 2007 and 2010, as well as earlier versions but probably in a slightly different guise. Have a bit of a poke about a bit.

2.2. Just sign here, here and here

Our second issue, accessing the “security” window and then the “macro security” window using the above “toolbar button” method (anything with the word “macro” in was disabled from a UI point of view in the ribbon/menus so you had to load the “security” window to get there) we could see that only signed macros were allowed to run. 

Nightmare, what can we do now? Thankfully during the above macro editor poking I had browsed through the office folder (looking for a VB Editor.exe type thing) and noted the following executable. 

Run this: C:Program Files (x86)Microsoft OfficeOffice12selfcert.exe


Run it – Create a certificate. Access the VB Editor using the steps in the previous tip.


Tools -> Digital Signatures -> Choose Certificate -> Select your cert.

Now it’s signed you will probably need to exit word/excel/whatever and reopen the document (we had to when testing).

2.3. …but wait, mommy told me not to run macros from strangers.

Okay so we’ve now got a macro, it’s signed but it still won’t run. They’ve hobbled the security even further and “disabled” any prompts we’d get allowing us to “run” a macro with a self-signed cert, so we’re going to have to find a way to explicitly trust our self-signed macro.


Open the VB Editor as before. Then Tools -> Digital Signatures -> Choose -> View Certificate – > Details -> Copy to File


Navigate to saved .cer file (just accept the defaults in the export wizard), right click and select “install certificate”, Select the location to install the certificate as “Trusted Publishers”.


Certificate Installed Successfully. You just added your certificate to the trusted signatures that microsoft office will blindly accept without needing you to click on a “accept the risk” style warning. 

Before (but this would typically be hidden and not shown to users, meaning that they would not have the option of “accepting anyway” in this manner and so self-signed macros would never run):

After (No prompt, macro can be run, certificate is trusted):


 You may need to restart word or whatever at this point just to get the changes to refresh but your macro will run without hindrance once done.

2.4 So what can I do with these things anyway?

So the mini-nftf in section 1 above, without cscript.exe/wscript.exe you’re a bit screwed.

How about doing it in VBA.

Sub run_me
     retVal = Shell(“C:WINDOWSSYSTEM32cmd.exe /k ftp”,1)
End Sub

A quick ‘F5’ and you’re back running the commands you need.

retVal in the above will contain the PID of the process you just launched so the following will kill the process too (in case you were doing something fancy) 

Sub run_me_kill_me
     Dim retVal as String
     retVal  = Shell(“C:WINDOWSSYSTEM32calc.exe”,1)
     killCmd = “C:WINDOWSSYSTEM32cmd.exe /k taskkill /PID ” + retVal
     retVal2 = Shell(killCmd,1)
End Sub

The “,1” part of the Shell call, that’s describing what you want VB to do with the window. If you are doing calls to a script (perhaps a macro that performs a bunch of commands on the sly?) or a command/console based program, you can use vbHide instead and no window will appear on the screen.

Be careful doing this on systems with CMD.exe disabled by group policy as you’ll find that they never show up and so persist within task manager waiting on an invisible but very real “This command has been disabled by your administrator, press any key to continue” prompt.

3. Help! No Web, No Hope? No Way!
Final tidbit of an NFTF – Ever wanted to write some VBS but never sure of exact syntax or even the functions you have access to, no access to the web and someone has helpfully disabled the “help and support” service, denying you any ‘F1’ action you may want.

This is a little trick I picked up from previous work. Providing the host you’re playing with has Microsoft office installed (else it’s worth just a general C: drive search for clview.exe).

You have all the scripting reference material you need to make whatever VBS you want.

First you make a new shortcut upon the desktop.

Set it to : “C:Program Files (x86)Microsoft OfficeOffice12clview.exe” “MSE” “Microsoft Scripting Engine”

Double click and a blank help screen will open (this does not require the help and support service yay!).

Search for something “VBS” for example and then click “microsoft scripting engine” (grey text, top left) and then “Microsoft Scripting Engine Help”, you’ll have help for VBScript and JScript language references along with information on all the juicy runtime objects you can access using VBS/JScript.

Note: JScript is essentially the same as VBScript (different syntax, but same capabilities), they’re all run using cscript.exe (if a console based script) or wscript.exe (if a dialog based script).

Need VBA help? Once again, CLVIEW comes to the rescue.

Create a shortcut for: “C:Program Files (x86)Microsoft OfficeOffice12CLVIEW.EXE” “WINWORD” “Microsoft Office Word”

Looks like it’s word help but it is the word developer reference and in turn will give you the full VBA language reference too.

Doing fancier application specific stuff in Excel? or Powerpoint? Change the above to suit.

Happy Local Lockdown Testing! 

NFTF: Pushing tags to Git Repositories – Converting puttygen keys to openssh versions

I’m working on a side project that has me contributing to a GIT repository for source control. Great! Only I haven’t got a freaking clue how to use it properly. First in the list: Pushing “Tags” up to the master repository First thing to note is t…

I’m working on a side project that has me contributing to a GIT repository for source control.

Great! Only I haven’t got a freaking clue how to use it properly.

First in the list:

Pushing “Tags” up to the master repository

First thing to note is that tags are typically only noted on your local copy of the repository. They aren’t pushed up to the origin when you make a Git Push, unless you specify otherwise.

This is fine and dandy if you’re using the command line git client from the off. Me, I was using TortoiseGIT on windows, bypassing the whole setting up of GIT Bash and there isn’t a simple checkbox that I’ve found in TortoiseGIT that says “push tags” along with a Git Push. So I needed to set it up.

The command that you have to run is:

git push origin --tags

This will push any tags that you have associated with your code (TortoiseGIT can create them by just rightclicking your repository and select “add tag”) up to the origin on your master repository (in my case hosted on assembla).

However before you get to that step you’ll need to have set up your GIT Bash first, and in my case as assembla uses PKI for authentication I would need to either:

a. Create a new key for the same computer, just for the GIT bash instance and add it (what i’ve typically done in the past, but loathed because it’s just duplication of effort)

b. Figure out why “export OpenSSH version” of my keys from puttygen has never actually just worked for me.

This time around I opted for b.

Converting PPK to id_rsa

I found this answer courtesy of stackoverflow and a user called Kaleb Pederson it is as follows:

  1. Open PuttyGen
  2. Click Load
  3. Load your private key
  4. Go to Conversions->Export OpenSSH and export your private key
  5. Copy your private key to ~/.ssh/id_rsa (or id_dsa).
  6. Create the RFC 4716 version of the public key using ssh-keygen
  7. ssh-keygen -e -f ~/.ssh/id_rsa > ~/.ssh/
  8. Convert the RFC 4716 version of the public key to the OpenSSH format:
  9. ssh-keygen -i -f ~/.ssh/ > ~/.ssh/

With that done, your GIT bash should now be able to authenticate correctly to your Git repository using the PPK you already use for TortoiseGIT.