NFAL – Episode Two: Thin Clients and why I like playing with them…

Why do I get excited whenever I am presented with a thin client, with an RDP or CITRIX or VMWare View session to a backend virtualised desktop?

Because you can almost guarantee the thin client is the easiest local lockdown check you’ll ever do.

There are some caveats to this in that thin clients using some custom *nix firmware can be stupidly hard to do anything with locally at least, however if you see any of the embedded OS style thin clients, well chances are you’re already administrator on that device you just didn’t know it.

Let’s take a common terminal I see knocking about, the Wyse terminal. Its principle defence against you is that of the “restricted account” and its “file based write filter” with that filter turned on, everything you do is only temporary.

Due to the FBWF, doing patching and updates on the OS really is a pain in the arse, add in the normal situation that the devices they are rarely controlled by GPO preferring to be controlled by a local policy instead and you’ve got yourself a tasty burger.

So first, what is this restricted account thing I’m talking about? Well on Wyse both the “user” and the “administrator” accounts are local administrators. The only difference is that the User account Sid is listed within a “restricted profile” registry key. Any accounts not in that have full access to the underlying OS.

So first, get yourself a shell. Pop it via any of the means I’ve discussed previously (to come in a future blog post). Even if you resort to dropping it on a USB and getting it in that way alternatively here is yet another “breaking the jail” method that worked pretty well on an XP Embedded thin client.

As the normal user, open up printers and faxes, using the view menu open the folder bar. Now browse the ram drive based file system to either create or find an “unknown file” you need something that windows doesn’t know how to open. Double click and you’ve got the open with dialog. Within this, specify a path to an executable you wish for the file to be run in. Make this path c:\windows\system32\command.com. (If its windows 7 pop powershell.exe or powershell_ise.exe instead) Hit okay and apply or whatever you need to confirm your change and get out of the dialog.

What happens next is interesting, command.com will spawn, fail to understand the actual file and then drop you to a command prompt.

It won’t have a system path so every command will have to be fully written out but it will work. I suggest doing:

cd c:\windows\system32

Before doing anything else, swiftly followed by as remember every account is local admin on this terminal and the only controls are a write filter and a restricted profile registry key:

net.exe user /add hacker password123

net.exe localgroup administrators hacker /add

Now you need to log off, which is not as awkward as you think given there are no menu options for that on the restricted account and chances are ctrl alt del doesn’t let you either.

shutdown.exe -l -t0

Enter this command and hold down the shift key. You don’t want to restart the machine or the FBWF will reset everything and you don’t want it auto logging in as the user account either which the shift key should help with. When the Wyse terminal finally logs off, login as your hacker user.

Voila, you’re now local admin on the box, with a full desktop and no application controls applied as your Sid is no longer the one listed as a restricted profile. Disable the FBWF, now any change you make will be permanent, install that key logger or bind shell and have fun.

Bypassing Group Policy Proxy Settings using the Windows Registry

Latest Update: 12/12/2013 - Scroll down to view.

Foreword: Irresponsible Disclosure?

I have tried to report this to Microsoft Security Response Center (@msftsecurity) and received this response:

Hello,

Thank you for contacting the Microsoft Security Response Center (MSRC). What you’re reporting appears to be a documentation issue rather than a security vulnerability. To best resolve this issue, please contact Microsoft Product Support Services at http://support.microsoft.com/common/international.aspx or make a report at http://support.microsoft.com/gp/contactbug/. If you still believe this is a security vulnerability, please let us know.

Following either of the above links points to their support channels, which require a valid support agreement (which I don’t have) or require it to be one of the listed “accepted bug report” programs available through connect. Which I couldn’t find a suitable program to class this under, coming up against a brick wall and given the MSRC response suggesting that this is not a security bug I’ve decided to do a blog post disclosure. This is what follows.

The What?

This issue stems from the ability as an non-administrator user to circumvent group policy based settings that seem to imply a disablement or prevention for a feature, in particular this was first noticed when examining the proxy settings of a host, originally editable from within the Internet Explorer connections tab.

The policies in question have the following wording:

  • “Disable the Connections Page”
    • The above policy infers within its description that no other policies are required to ensure the protection of the connection settings. From experimentation, this appears to be an incorrect assumption.
  • “Prevent Changing Proxy Settings”
    • This policy appears to only “grey” the GUI, it does not prevent actual changing of the proxy settings, and fails to set ACLs or harden the settings sufficiently against attack
  • “Disable Changing Automatic Configuration Settings”
    • This policy appears to suggest that it blocks the modification of the auto configuration URL and prevents a user from modifying the “Detect Settings Automatically” checkbox. However as per the previous proxy settings policy, it merely affects the appearance of the GUI and does not protect the settings from modification by a non-administrative user.

The How?

Setting Up…

  • Create a local user on your machine, don’t add him to any special groups. In fact you just want a non-administrator, someone you’d not expect to be able to bypass a group policy.
  • Using ‘gpedit.msc’ as an administrator, navigate to the following root and enable “Disable Changing Automatic Configuration Settings”.

Root: User Configuration/Administrative Templates/Windows Components/Internet Settings/

  • With that setting enabled and a user created. Log out of your administrator account, log back in as the user under test.
  • Open Internet Explorer and view internet settings, navigate to the connections tab and view the Lan Settings. It should appear as per the screenshot below.
Checkbox is populated, Policy is enforced.,
Checkbox is populated, Policy is enforced.
  • You will be unable to change the “Automatically Detect Settings” Tick box.

…Exploitation

  • Now fire up regedit (this can also be done via VBA, VBS, BAT, Powershell, WMI, whatever you need to access registry keys).
  • Alter the registry key/value of:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings

Changing the registry key
Changing the registry key
  • Edit it so that the 09 becomes 01, or rather subtract 8h from the 9th byte of this value.
  • Now reload up Internet Explorer and view the Lan Settings once again.

Checkbox no longer populated

  • Voila, Policy is still applied but settings have just been edited by yourself.

Summary

Okay so the issue in the above example is not a huge one, unless there is a second route out of the network (or one you manufacture one as an authenticated attacker) its of limited use.

However it highlights what could be a possible security issue with other Group Policy Objects. A GPO in my opinion that states it prevents modification or changing of an item should do exactly that, however these policies only appear to disable the GUI interface, the actual sensitive data that should be protected is freely accessible and worse still, editable by a normal non-administrator user.

Granted, a sysadmin is going to apply more than just GPO to his machine and registry keys and registry editing facilities should indeed be acl’d away so only administrative accounts may alter the settings but the documentation on MSDN and within the GPEDIT tool itself suggests that these policies should be sufficient to prevent user modification of the named settings which clearly is not the case.

I intend having a poke about myself to see where else Microsoft deem it sufficient to disable the GUI but still allow write access to the registry keys that actually hold the sensitive data, if any of you (1?) readers of the blog find any, be sure to post it in the comments below.

Update:

Quick two second google turned up this beauty: http://msdn.microsoft.com/en-us/library/ms815238.aspx which lists all the GP objects and the registry keys they affect, looks like I have an exciting time reading through accessenum output ahead of me. HKCU stuff is usually a safe bet (aside from some keys contained in “policies”) for being editable.

Update #2:

So after a conversation with a colleague of mine I’ve realised that perhaps the severity of this issue may be lost in the abstraction of the above from a client system where I initially encountered it. The above issue will allow you to take over the control of the computers proxy settings at will, what follows is a “what if” scenario explaining the issue in detail.

Bob is in his local museum. They provide a kiosk based system there for viewing a few museum webpages that describe various exhibits, it also allows users to access facebook to “like” and “share” and a few email services for free.

Bob is a clever chap however and despite having no address bar and no normal route out of the Kiosk jail, he sees a “terms and conditions” link which appears to link to c:\kioskfiles\terms.docx

docx?!? So word viewer must be installed? no way would the museum have built the kiosk based upon a corporate build and then locked it down?

Bob clicks the link, Word 2010 fires up and displays the terms and conditions for using the kiosk. Oh, now life gets interesting, Bob is a follower of @scriptmonkey, and remembers his post on macros and code execution so he breaks out the macro editor and runs a few commands, command prompt is no go, due to GPO but oddly regedit is accessible, granted he’s only the lowly kiosk user at the moment so what can he do?

Bob decides he wants to harvest credentials.

Using regedit bob checks the contents of:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable

and finds that it is set to zero which means no proxy is involved, okay but what about the contents of the autoconfiguration settings.

He heads over to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings

Checks the value and finds the 05 set right where the 09 would be if it was enabled for auto detection. (05 means use autoconfiguration script, but not auto detect)

Now he confirms what the URL is hard set to at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL

Bob edits the AutoConfigURL to point at C:\doesntexist.txt and tries browsing to a website not explicitly allowed, one that would result in a blank white page normally. Pow! the website pops up.

It appears the kiosk is on the wider network just forced to connect via a proxy first to enforce the site rules.

Perfect, now Bob sets the DefaultConnectionSettings key such that the 05 from before is now set to 01. Meaning that no auto configuration script or automatic detection takes place. He sets the EnableProxy key to 1, to enforce a proxy setting. He then adds his own internet based proxy to the registry key ProxyServer.

Confirming he still has internet access, he closes his open windows and walks away.

Few minutes later Jane comes along. Clicks the facebook “share this exhibit” button, logs in…

What just happened? (TL:DR)

The ability to modify the proxy settings for current user and bypass group policy protections as a normal non-administrator user is a particular risk to shared user based systems, Demo machines in PC World, kiosks, “sheepdip” machines, etc…

A malicious user is able to compromise the system, redirect traffic (in the case of internet explorer its often the case that other programs follow IE’s settings) to their own proxy server, harvesting credentials, sensitive data/information, etc…

In the example above I used regedit but this is possible using VBA/VBS/Batch/WMIC as well, meaning there is more than one way to skin this particular cat.

The GPO based protections that prevent access via the GUI should also prevent modification of these settings via the registry. In addition the modification of these keys do not appear to be documented anywhere within the above linked table, in fact those listed registry keys only list “policy” based keys, which just confirm whether or not the policy is set in this case instead of providing the enforcement of the particular rule.

So, whats your opinion? Were MSRC right to classify this “not a security vulnerability”?

Update #3:

It appears a chap has seen this blog post and did some more work on understanding the PAC file contents (array.dll?script if you’re running a TMG) and has now developed a sweet little post exploitation metasploit module to perform DNS spoofing against a compromised host.

https://github.com/rapid7/metasploit-framework/blob/master/modules/post/windows/manage/ie_proxypac.rb

Epic stuff. :)

BSides London 2013: Blinking Hell – Extracting data using Keyboard Lock States

So hopefully if you’re reading this you’ve seen mine and Matt Phillips (@phillips321) talk about Blinking Hell in the Rookie Stream at BSides London 2013.

Photo of @Phillips321 and @Scriptmonkey_ presenting Blinking Hell, courtesy of @Andrew_Barratt

What follows is a more in-depth blog post I hope that contains some of the timeline and reasoning around some of the things we did and why we did them.

For those of you who are fresh to this and don’t know what Blinking Hell is, it’s a sysadmin/security dude’s worst nightmare. It’s someone bypassing all your host based protections and extracting your crown jewels without leaving too visible a trace.

What is Blinking Hell?

Blinking Hell makes use of a small arduino like programmable USB device. The Teensy, created by Paul J Stoffregen as a small programmable USB device it seems to be able to emulate any USB device under the sun and is used in various projects including converting real flight controls into computer flight simulator input, repairing dance pads or maybe you’ve heard or used one with the Social Engineering Toolkit, courtesy of the research and work put in by IronGeek and David Kennedy. It allowed a new way of wrapping payloads onto a device that could type extremely fast.

People soon turned their teensy’s into FTP/HTTP/Etc network clients of awesome, plugging in and exporting data left right and centre. Fantastic! But, what if you don’t have internet access?

What if the system you’re trying to get data off of is not allowed to browse the internet willy nilly? What if you didn’t need the internet?

Okay, but then i’d just use a USB Drive like normal…

Nope, not in this case. In this case they’ve prevented write access to USB drives using host based endpoint protection mechanisms. Heck in some cases you can’t even get the USB device to be recognised as plugged in thanks to things like Lumension Endpoint Security (aka Sanctuary) for example.

Drat… you say, YAY! I say.

Challenge accepted.

How do you do it?

So the basic premise.

1. Write some code that does something that magically transports data off of the disk.

2. Get the teensy to inject code, or supply the code via other means (other employee internally emailing it?, bring it through import/export procedures).

3. Now you’ve injected the code, run it.

4. Knowing where the crown jewels are stored

5. Saving it to disk

6. Exfiltration of data.

So, How do you get data off of a system, you can’t get data from?

This boils down to what ways can the teensy see data?

My colleague way back in 2010, managed to get to go on a nice trip to Defcon and saw a lovely talk by the aforementioned David Kennedy, he was also perfectly placed to grab a free teensy when he threw a few out to the crowd at the end of his speech.

My colleague managed to also have a quick chat during which he asked if the teensy could be used for output in the keyboard configuration and David said something along the lines of “I don’t see how it could, its just a keyboard”.

My colleague is a determined person and left thinking “there must be a way”. A few weeks/months of research and he stumbled upon a bit of documentation regarding PS2 keyboards and their control lines. This documentation noted that the “lock state” LEDs were “broadcast” signals that would be seen by any PS2 devices plugged into the host. Does the same hold true for USB?

Well in his blog post back in August 2011, he revealed it: http://www.phillips321.co.uk/2011/08/25/teensy-keyboardlockkeys/

Back then I was just a lowly software coding monkey on another project, in the same company but not within the penetration testing field, however as of September 1st 2011 I got accepted into the penetration testing team and started getting to know the team. This is when Matt revealed his research project above to me. Having done a bit of hacky development work I thought I could contribute and so volunteered my services. I didn’t get much done until one night in October 2011.

Eureka!

I had spent all evening working on it, until finally at 10 past midnight on the 25th of October 2011 I published a video to my facebook pages confusing my friends except the few that understood what I had achieved.

I had gone from Text file -> Bytes -> Binary Bit Stream -> Signalled using keyboard Lockstates -> Saved internally on the Teensy’s SD Card (or eeprom depending on the implementation I used).

If I knew how to export it elsewhere and host it somewhere I would. It was rough but it was ready and it worked.

Then I left it…. Me and Matt talked about dedicating some time to polishing it but conferences came and went and we were both too nervous to stand in front of an audience and do a long talk about it. Then came September 2012.

B Sides London 2013 Call for papers and introducing a new Rookie Track, 15 minute talks in front of a small audience with an experienced mentor to guide you. It seemed perfect. We wrote up a small abstract in a canteen over lunch and submitted our talk.

Disaster!… (almost)

November 2012 we had notification we had been accepted and then came a bombshell in the form of a “WTF?!?” message over facebook from Matt. He sent me a link to hack-a-day.

http://hackaday.com/2012/10/30/extracting-data-with-keyboard-emulation/

Someone had “published”.

But they had a flaw, they used custom executable code. That just won’t fly on our systems I don’t want to have to run an executable. I want it to work across locked down systems that use whitelists for these things so we used macros. Something I’m pretty familiar with having been working on a local lockdown project for a fair while now. You can find some of the things I’ve done with macros over at: http://blog.scriptmonkey.eu/nftf-local-lockdown-getting-prompts-fun-with/

Long story short, We still had our talk! :) *phew!*

So now without further waffling, we get to the important stuff.

Rough edit of our presentation video with slides: BSides London 2013 Rookie Track Presentation – Blinking Hell

The code to get this working on your own teensy can be found here: https://www.assembla.com/code/blinking-hell/git/nodes

The slides I’ll get up on slideshare over the next few hours and are now available here: http://www.slideshare.net/RILHicks/blinking-hell

My colleague has uploaded the in-talk video at: https://www.youtube.com/watch?v=N8nyt4ugTnE

I’ve uploaded an earlier video that we made with older code, but it shows more of the debugging output and juicy techie stuff: http://www.youtube.com/watch?v=a_O0eBFShaY

Apologies for the poor attempt at narrating it but figured I’d best explain some aspects of it.

Whenever we get the whole presentation video we plan on sharing that too! See above for the presentation video 😉

I hope you enjoyed our talk and I can hand on heart say it was enjoyable to do and hearing the feedback in the breakout room afterwards some of the suggestions made were interesting, watch this space you may see some of those interesting developments soon(ish).

Notes from a lockdown: Episode 1

So I’ve done a few posts in the past about getting command prompts from GPO’d workstations and running what’s known as “mobile code” in locked down environments (VBA, VBS, BAT, Bash, Python, Perl, etc…). I figured I’d try and make a series of sh…

So I’ve done a few posts in the past about getting command prompts from GPO’d workstations and running what’s known as “mobile code” in locked down environments (VBA, VBS, BAT, Bash, Python, Perl, etc…).

I figured I’d try and make a series of shorter posts maybe detailing some of the things I’ve discovered while working on my current long term engagement (involves lots of local lockdown playtime).

Lesson 1: Just because you can’t run reg edit doesn’t mean you can’t edit reg

The following methods can all be used to edit registry keys, create full trees down to a value or otherwise modify the registry.

VBS – Difficulty: Easy

function writeReg(regPath,value,regType)

'reg_sz = String, reg_dword = integer, reg_binary = binary or boolean

'reg_expand_sz = expandable string (like a path of %systemroot%), reg_sz = string

Dim objReg, keySet

objReg = CreateObject("WScript.Shell")

key = objReg.regWrite(regPath,Value,RegType)

writeReg = key

End Function

'Now to call the function above.

disposablevar = writeReg("HKCU/scriptmonkey/regwriting/1","Success!","REG_SZ")

VBA – Difficulty: Easy (depending on lockdown of office suite, see: Getting Prompts & Fun with macros for details of circumventing that)

'This all relies upon a small function available within word called privateprofilestring.

Sub regReaderEditor

'To Write

System.PrivateProfileString("", _   "HKEY_CURRENT_USER/scriptmonkey/regwriting","2") = "Success!!"

'To Read

disposableVar = System.PrivateProfileString("","HKEY_CURRENT_USER/scriptmonkey/regwriting","2")

msgbox disposableVar

End Sub

VBS with WMI – Difficulty: Could end up in a moment of WTF?

The reason for the difficulty increase?

The way that WMI handles registry writing by calling different functions for different types of registry key that you wish to write, It also involves scary hexadecimal numbers to refer to the various hives. I can barely count to 10, let alone F.

The script snippet that follows is available in better syntax highlighting glory along with a bunch of other interesting WMI scripts over on the MSDN documentation pages, so go and check them out when you have time, but this is one i’ve used in the past with success.

Const HKEY_LOCAL_MACHINE = &H80000002

strKeyPath = "scriptmonkey/regediting/"

strComputer = "."

Set objReg=GetObject( "winmgmts:{impersonationLevel=impersonate}!" & _ strComputer & "rootdefault:StdRegProv")

strValueName = "3"

strValue = "Success!!!"

objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

Script.Echo "Example String_Value at " _& "HKEY_LOCAL_MACHINE/scriptmonkey/regediting"

Finally a gem from my colleague over at http://www.pentestdave.com (go and say hi)

Always remember, even though you may be acl’d out of HKLM. HKCU is typically always editable by the current user.

I’ll leave it up to the reader to discover what that means for now, but I am working on a tool that’ll make use of that fact quite a bit.

Have a tip to share? give me a shout in the comments or if you want a more private chat head over to my twitter @scriptmonkey_ and give me a nudge over there.

blog.scriptmonkey.eu

So after a bit of a drinking session with some lads I’m working with and lots of teasing of a fellow tester attempting to get him to buy a (rather cool in my opinion) domain name, i’ve just gone and got this blog its own proper home on the web. No…

So after a bit of a drinking session with some lads I’m working with and lots of teasing of a fellow tester attempting to get him to buy a (rather cool in my opinion) domain name, i’ve just gone and got this blog its own proper home on the web.

No longer using my personal domain from yonks ago, it now is officially:

http://blog.scriptmonkey.eu

So there you go! Update your bookmarks (all 1 of you :)). I’ll try and get a cname redirect set up on the old address for the time being but yeah this blog finally has a proper home on the web.

For those who didn’t know I maintain a twitter feed @scriptmonkey_ its nothing fantastic and I rarely post anything up there that isn’t here but its another way to get hold of me if you have any questions about my blog content.

Look out for more frequent postings too, have a few research projects in the pipeline that are about to all come to fruition providing I can get enough time to get a move on.

P.S. I use 123-reg for my registrar and they appear to have an awesome deal on for .eu domains right now (hence my purchase). 1 year for 99 pence. Might be worth checking out if you’re interested in having your own “identity” on the web.

NFTF: Bypassing Group Policy Denied Command Prompt

This is an old trick but I ended up doing it the other day just for kicks, it will only work on 32bit systems at the moment (edit.exe is a 16bit editor and won’t run on a 64bit OS). Just to clarify – I had no internet access or access to any tools…

This is an old trick but I ended up doing it the other day just for kicks, it will only work on 32bit systems at the moment (edit.exe is a 16bit editor and won’t run on a 64bit OS).

 

Just to clarify – I had no internet access or access to any toolsets, so had to go with whatever I could find on the box hence the use of edit.exe and not winhex/hxd/hexeditorofyourchoice.

 

I think I vaguely recall a way to use debug.exe to edit binary files but it involved raw assembler and was more complicated than I could remember off of the top of my head with zero internet access at the time so this will do for now.

 

Right, so as before we have access to a basic command prompt using the VBS/VBA “Call FTP and ! prefix your commands” method.

 

But I want a full prompt that works without needing such a workaround.

 

Copy C:windowssystem32cmd.exe somewhere (unless you want to possibly break cmd.exe on your test system).

 

Using the VBS/VBA FTP method, call “Edit” (Don’t try this with notepad it will change all of the nulls to x20 and destroy the file such that you can no longer run it as an executable)

 

File -> Tick the “Open Binary” box (This is important), Navigate to C:windowssystem32cmd.exe and open the file.

Edit_binary

 

Scroll down (I’ve tried searching and as there is no way of typing a null char, it won’t work) and you’re looking for the first references to “SoftwarePolicies…” Its the registry key that it is looking at to determine if it should allow you to run or not.

Edit_policies

Change P O L I C I E S to B O L I C I E S (well whatever you want, keep the length the same though)

 

Save the file – Run the file – Voila! command prompt with no need to have to go through FTP.exe over and over. 

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

 

Macro_bar

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

Selfcert

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

Signing_word

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.

Signing_big

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

 

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

Next…

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):
Untrusted

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

 
Trusted_nowarningTrust_center

 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!