|The NJ PowerShell User Group is having a meetup on Thursday, January 8th from 6:00 – 8:00 PM. If interested, please register through the Eventbrite website to track attendance for ordering pizza. For those attending online (Webex) we will send a follow-up email with the meeting link based on Eventbrite online registrants.
Please note that the Webex meeting will start at 6:00 PM, but the actual presentation won’t start until 6:30
Presenter: Doug Finke
Bio: Doug Finke, author of “PowerShell for Developers”, a Microsoft Most Valuable Professional (MVP) for PowerShell and works at Start-Automating, a company specializing in all aspects of PowerShell development, including consulting, training and tool building. Doug has been a developer and author working with numerous technologies. You can catch up with Doug at his blog Development in a Blink at http://dougfinke.com/blog.
Microsoft Most Valuable Professional (MVP) Doug Finke takes us through PowerShell from a developer’s point of view. Doug shows techniques for integrating/debugging PowerShell from
NJ PowerShell Meetup Coffee Bar and Conference room at Mathematica Policy Research
We’ve been working feverishly to go through all the great presentation abstracts and make our selections. Everyone submitted really good abstracts, so if don;t receive an email by the end of the week, please understand that we only had so much room available. This has been a difficult process, but we think we have built an excellent show for the NA 2015 PowerShell Summit.
We will be sending emails to the accepted speakers for confirmation by the end of the week. WE will then post the agenda after we have had confirmation.
At the 2nd of October, Lee Holmes gave a presentation about the current and future state of the Windows Management Framework (WMF) during the Dutch PowerShell User Group (DuPSUG) at the Microsoft headquarters in The Netherlands.
The slide decks and recorded videos will be made available soon, but this is what was discussed:
The release cycle of the Windows Management Framework (WMF)
Faster incremental releases of preview versions are being released. This rapid development means that companies that need specific new functionalities to tackle current problems they’re having, don’t have to wait as long as they had to in the past.
Everyone should keep in mind that documentation for preview versions can be more limited, but should still read the release notes carefully. They contain descriptions of some of the improvements that are discussed in this blog post, but also cover other things that aren’t discussed here. Also be sure to take a look at What’s New in Windows PowerShell at TechNet.
A request from the audience was to include more helpful real-life examples until documentation is fully up-to-date.
Desired State Configuration (DSC) partial/split configurations
With DSC partial/split configuration it is possible to combine multiple separate DSC configurations to a single desired state. This could be useful when a company has different people or departments that are responsible for a specific part of the configuration (by example Windows, database, applications).
OneGet is a Package Manager Manager (it manages package managers). It enables companies to find, get, install and uninstall packages from both internal and public sources. Public repositories can contain harmful files and should be treated accordingly.
Besides the OneGet module included in the Windows Management Framework Preview, updated versions are continuously being uploaded to https://github.com/OneGet/oneget by Microsoft. These can include bug fixes and new functionality like support for more provider types.
While in the past it seemed that Nuget was required, during the PowerShell Summit it was demonstrated that a file share can be used as well.
From the audience a question was raised whether BITS (Background Intelligent Transfer Service) could be used. This is currently not the case and there were also no plans yet to implement it.
PowerShellGet is a module manager which should make it easier to find the many great modules that are already available, but are not very discoverable because they’re fragmented on numerous websites across the Internet.
Microsoft is currently hosting a gallery of modules. The modules that are available in there are currently being controlled by Microsoft, but this might change in the future.
It is possible to create an internal module source and the save location for modules can be specified as well.
PSReadLine is a bash inspired readline implementation for PowerShell to improve the command line editing experience in the PowerShell.exe console. It includes syntax coloring and CTRL+C and CTRL+V support, for more information about other improvements, view their website.
PSReadLine is one of the modules that can be installed using PowerShellGet:
Find-Module PsReadLine | Install-Module
- Always be careful when running scripts that include Invoke-Expression or its alias iex because it might run harmful code.
- For a non harmful example, take a look at this blog post by Lee Holmes.
- Many people in the security community are adopting PowerShell.
- PowerShell is done in memory and is therefore volatile. To improve security the following enhancements were introduced:
- Transcript improvements
- Transcript support was added to the engine so it can used everywhere, also in the Integrated Scripting Environment (ISE).
- A transcript file name automatically includes the computer name.
- Transcript logging can be enforced to be redirected to another system.
- Transcription can be enforced by default.
- Transcript improvements
- Group Policy
- An ADMX file is currently not available to configure it on all platforms, but it can be found in the technical preview versions of Windows 10 and Windows Server under: Administrative Templates -> Windows Components -> Windows PowerShell
- More advanced Scriptblock logging
- Enable ScriptBlockLogging through GPO (in later Windows versions) or by registry by setting EnableScriptBlockLogging to 1 (REG_DWORD) in: HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
- The additional logging will show you what code was run and can be found in event viewer under Applications and Services Logs\Microsoft\Windows\PowerShell\Operational.
- Scriptblocks can be split across multiple event log entries due to size limitations.
- Using Get-WinEvent -FilterHashTable it is possible to get related events, extract the information and combine it.
- Since attackers would want to remove these registry settings and clear event logs, consider using Windows Event Forwarding/SCOM ACS to store this information on another server. Also consider enabling cmdlet logging.
- Just Enough Admin (JEA)
- JEA enables organizations to provide operators with only the amount of access required to perform their tasks.
New and improved functionality and cmdlets
Manage .zip files using Expand-Archive and Compress-Archive
.zip files can be managed using Compress-Archive and Expand-Archive. Other archive types like .rar are not currently supported, but this might be added in future versions.
It is now not necessary anymore to specify the item type. To create a new item, simply run
This makes it easier to get the value of a file or registry:
- Get-ItemPropertyValue $Env:windir\system32\calc.exe -name versioninfo
- Get-ItemPropertyValue-PathHKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\ScriptedDiagnostics -Name ExecutionPolicy
Symbolic links support for New-Item, Remove-Item and Get-ChildItem
Symbolic link files and directories can now be created using:
New-Item -ItemType SymbolicLink -Path C:\Temp\MySymLinkFile.txt -Value $pshome\profile.ps1
New-Item -ItemType SymbolicLink -Path C:\Temp\MySymLinkDir -Value $pshome
Junctions cannot currently be created, but this might also be added in a later version.
Debugging using Enter-PSHostProcess and Exit-PSHostProcess
Let you debug Windows PowerShell scripts in processes separate from the current process that is running in the Windows PowerShell console (by example long running or looping code). Run Enter-PSHostProcess to enter, or attach to, a specific process ID, and then run Get-Runspace to return the active runspaces within the process. Run Exit-PSHostProcess to detach from the process when you are finished debugging the script within the process.
Use Psedit to edit files in a remote session directly in ISE
Simply open a new PSSession to a remote computer and type PSEdit <path to a file>.
Classes and other user-defined types
- The goal is to enable a wider range of use cases, simplify development of Windows PowerShell artifacts (such as DSC resources), and accelerate coverage of management surfaces.
- Classes are useful for structured data. Think by example about custom objects that you need to change afterwards.
- Name of the class and the constructor must be the same.
- Code is case insensitive.
- In classes, variables are lexically scoped (matching braces) instead of dynamically scoped.
- Every return must be explicit.
- Sample code:
Fellow PowerShell MVP and author Jeff Hicks has released a free ebook on PowerShell and Hyper-V which was sponsored by Altaro. The ebook is a cookbook style of recipes for managing a Hyper-V infrastructure and virtual machines. The eBook briefly discusses how to you use each recipe. All scripts and functions are included in a separate zip file.
Visit http://www.altaro.com/hyper-v/new-ebook-altaro-powershell-hyper-v-cookbook/ to learn more and download your free copy.
Aside from classes and new DSC features, which I’ve already written about, there are a number of less-headline, but still-very-awesome, new capabilities.
This article is based on the September 2014 preview release of WMF 5.0. Information is highly subject to change.
First up is the ability to automatically create PowerShell cmdlets from an OData endpoint. Huh? OData is a kind of web service (basically); PowerShell gains the ability to look at the endpoint and construct a set of proxy cmdlets that let you interact with the endpoint more naturally. This is spiritually similar to what PowerShell can already do for a SOAP web service endpoint.
Next are some 7-years-overdue cmdlets for managing ZIP files: Compress-Archive and Expand-Archive. Finally. These use underlying .NET Framework ZIP functionality (I think), which has had some compatibility problems in the past, so we’ll see how these hold up. But they should be the missing link to letting you do everything DSC-related right in PowerShell, since you can now ZIP up your custom resources for deployment via pull server.
Auditing gets a huge win, and this is really more of a headline feature than people think. For one, the ISE now supports transcript creation. Yay! You can also “nest” transcripts, meaning you can have one running, and then start a second one to cover only a portion of time. Closing the second one lets the first remain running. You can also specify a central transcript directory, which is useful when you want to collect these things into a central folder for reporting. For example, you should now be able to set up Remoting endpoints that automatically kick off a transcript when someone connects, and saves them to that central location.
More auditing comes in the form of Group Policy settings. You’ve always been able to log the fact that certain commands were run (did you know that?), but now you can enable detailed script tracing that logs a crapload of detail to the PowerShell operational log (which can, like any other event log, be forwarded to another server). You get the complete details of every script block executed, even if it creates another script block. Again, this is set up in Group Policy – check out the WMF 5.0 release notes for the location.
Ed Snowden gets a face slap with new Cryptographic Message Syntax (CMS) cmdlets, including Get-CmsMessage, Protect-CmsMessage, and Unprotect-CmsMessage. These use PKI to encrypt data. By the way, if your organization doesn’t already have an internal PKI, WTF are you waiting for, you’re ten years behind the curve, man. PKI becomes more important to Windows environments every single day, and you need to get with the program.
There’s also a new fun feature for extracting content from strings. This system uses some Microsoft Research functionality called FlashExtract. Essentially, you give it examples of what your data looks like, and then point it to a big string (like a text file) full of data. It can extract all the data pieces based on your example. It’s early days for this technology, but it’s kind of awesome to see the PowerShell team giving us an easy way to play with it.
Because WMF 5.0 introduces PowerShellGet, it now includes commands to add PowerShellGet repositories. That means you can stand up your own repo, host your modules there, and install modules by simply running Install-Module (or find them using Find-Module). Tres awesome! We don’t yet have technical details on what the heck a PowerShellGet repository actually looks like, but I’m sure that’ll crop up.
ARE YOU PLAYING WITH WMF 5.0 ON A NON-PRODUCTION VM YET? YOU SHOULD BE. Times are changing and you gotta keep up!
When Desired State Configuration (DSC) came out – gosh, just about a year ago – I kept telling people that there was more to come. And a lot of it is now just around the corner in PowerShell v5.
This article is written to the September 2014 preview release – things may change for the final release.
A major set of changes in DSC is a much more detailed and granular configuration of the Local Configuration Manager (LCM), the local “agent” that makes DSC work on the target node. This new level of configuration really shows you where Microsoft’s thinking is.
For example, a single target node can be configured to pull configurations from multiple pull servers. That doesn’t necessarily mean separate machines, as a single IIS instance can host multiple websites, but it means you’re no longer limited to one MOF per computer.
Yes, I said that. The LCM can now pull (but not have pushed to it) partial configurations. Each partial configuration is a MOF, but the understanding is that there can be more than one. There’s still no dynamic evaluation of which MOFs will be pulled; you have to specify them all in the LCM configuration, but now you can break a machine’s total configuration into multiple bits. Each partial configuration is given a source, which is a pull server.
Each partial configuration can be given exclusivity over certain resources. This helps avoid overlap. For example, you might decided that Partial Config A has exclusive control over all xIPAddress settings, meaning those settings from any other partial config wouldn’t work. Partial configurations can also depend on each other, so that (for example), Partial Config B won’t even run until Partial Config A is complete.
The LCM can also have a separate server configured for web- or file-based resource repositories, meaning those can be separated from the pull server endpoint.
What used to be called the “compliance server” is now simply the reporting server – we mentioned in “The DSC Book” that the name of this would likely change. It’s now a distinct configuration item, meaning even a node in Push mode can report its status to the reporting server!
New global synchronization capabilities also exist. A node’s configuration can be made dependent on a configuration item from another node. Meaning, Node “A” won’t try to configure until Node “B” completes certain items first. Communications is all via WS-MAN and CIM.
A new Get-DscConfigurationStatus returns a high-level status for a node – similar to what the reporting server would collect – and an amazing new Compare-DscConfiguration can now accept a configuration and tell you where a given node differs. This is a big deal, and something a lot of folks wanted in PowerShell v4. There’s also an Update-DscConfiguration, which forces a node to evaluate its DSC stuff right away.
DSC is quickly coming of age. In less than a year, we’ve seen (so far) 6 releases of additional resources, and now with PowerShell v5 we’re seeing a number of important enhancements and evolutions in the core technology. Many of the things that frustrated folks initially are now taken care of.
This post is based on the September 2014 preview release of WMF 5.0. This is pre-release software, so this information may change.
One of the banner new features in PowerShell v5 is support for real live .NET Framework class creation in Windows PowerShell. The WMF 5.0 download’s release notes has some good examples of what classes look like, but I wanted to briefly set some expectations for the feature, based on my own early experiences.
The primary use case for classes, at this point, is for DSC resources. Rather than creating a special PowerShell module that has specially named functions, live in a specially named folder, and work in a special way – that’s a lot of special, which means a lot of room for error – classes provide a more declarative way of creating DSC resources.
But we’re a bit ahead of ourselves. What’s a class?
In object-oriented programming, a class is a hunk of code that provides a specific interface. Everything in the .NET Framework is a class. When you run Get-Process in PowerShell, for example, you are returning objects of the type System.Diagnostics.Process – or, in other languages, objects of the class System.Diagnostics.Process. Each process is an instance of the class. The class describes all the standardized things that a process can show you (like its name or ID), or that it can do (like terminate). Programmers build the functionality into the class itself.
Classes can have static properties and methods – these are hunks of code that don’t require an actual instance of a process. For example, you can start a process without having a process in the first place. The System.Math class in .NET has lots of static members – the static property Pi, for example, contains the numeric value of pi to a certain number of decimal places. The static Abs() method returns the absolute value of a number.
PowerShell classes are designed to provide similar functionality. The trick with PowerShell classes, at least at this stage of their development, is that they don’t add their type name to any kind of global namespace. That is, let’s say you write a class named My.Cool.Thing, and you save it into a script module named MyCoolThing.psm1. You can’t just go into the shell and run New-Object -TypeName My.Cool.Thing to create an instance of the class, because there’s nothing in PowerShell (yet) that knows to go look for your script module to find the class. That’ll likely change in a future release, but for right now it means classes are kind of limited.
The basic rule is that you can only use a class within the same module that contains the class. That is, the class can only be “seen” from within the module. So, your MyCoolThing.psm1 module might define a class, and then might also define several commands (functions) that use the class – that’s legal, and it will work. You still can’t use New-Object; instead, you’d instantiate your class by using something like ClassName::new(), calling the static New() method of the class to instantiate it. I expect New-Object will get “hooked up” at some point, but it might not be until some future version of PowerShell.
Anyway, back to DSC.
DSC is a bit unique, because normally you don’t load resource modules; the Local Configuration Manager loads them. When you build a DSC resource class, you’re forced to provide three methods: Get(), Set(), and Test(). The LCM loads your module, instantiates the class, and then calls the three methods as needed. DSC resources built in this fashion can live in a plain old module .PSM1 file – there’s no need to create a DSCResources subfolder, no need to have an empty “root” module, or any of that. So it’s a more elegant solution all around. Aside from some structural differences, you code them the same as you always have. v5 still supports the old-style resources, for backward compatibility, but class-based resources are the “way forward.” I expect Microsoft will eventually refactor the DSC Resource Kit to be class-based resources, as soon as they get a minute and as soon as v5 is widely adopted.
So most of the “wiring” behind classes has, to this point, been designed to support that DSC use case. In other words, of all the things a PowerShell class will need to do, the team has so far focused mainly on those things that impact DSC. The rest will come later – the release notes use the phrase, “…in this release” a lot, meaning the team understands where the current weaknesses are. “This release” in some cases may simply mean this current preview release, meaning they’re targeting more features for v5’s final release; in other cases, more features will have to wait for v6 (or whatever) or a later version of PowerShell.
So there’s a little rambling on classes and what’s presently in PowerShell v5. If you haven’t already downloaded the preview and started playing with it, you should; not in production, though. Keep it in a test VM for the time being.
This is the last call for speaker submissions to the 2015 NA PowerShell Summit due on September 15th.
We haven’t received the amount of submissions we would have expected, so if we don’t get enough submissions, then we’ll run a single-track event or… perhaps none at all. This is a venue for the community, and if there’s no participation, we may need to skip 2015 and try again in 2016. This is a labor of love (read unpaid) for the people that organize the event but we need your support by sending in submissions that you are willing to present. We have a strong attendee community and we need to give them a reason to come to the best PowerShell event in the world!
If you have already submitted your abstracts – THANK YOU!
If you have not presented before and have an interesting tale to tell about using PowerShell, then jump at the opportunity!
For detail, see this –
The Denver PowerShell User Group will be meeting again on September 4th and we will have Keith Hill presenting. Keith has published an ebook, is a repeat Microsoft MVP, and has been heavily involved in writing and maintaining the PowerShell Community Extensions.
You can find more information on the event as well as RSVP here:
I was speaking at TechMentor last week – a great and well-run conference – and it seemed I was overly using the phrase “You should speak at the PowerShell Summit”. I enjoy meeting old friends and making new ones at conferences, it’s one of the pleasures of working with people I enjoy the most. I not only learn about the latest challenges that the attendees face, but I learn very product specific knowledge from them. It feels like they should be the ones on stage talking about their latest foray into some deep dark corner of IT.
That’s when I started asking myself – “Why aren’t they speaking too?” So, I started asking that question, followed by a suggestion that they send in an abstract to speak at the PowerShell Summit. I was a little surprised by the look on their faces – as if I had suggested something that never crossed their minds. Well, it’s time that it crosses your mind.
I’m not here to convince you to speak, or encourage you in opening up additional career options; I’m suggesting that you have skills and experience that can help others. Why not share that?
Afraid to speak? There are a lot of things that scare me; writing books, speaking at conferences, teaching, fixing Exchange, etc. I’m afraid of many things that might result in failure, but I’m not willing to let that fear prevent me from trying new things – especially if I might be able to help someone else. In the words of my best mentor and friend: “Stretch yourself”.
This is my callout to you. This is me asking you to share your knowledge and help the community grow. This is me saying: “Stretch yourself”.
So, send in an abstract – it doesn’t mean you will get chosen (that’s not a failure BTW) but it does mean you’re trying to help. Good for you!
Cody Konior brought us this:
An entertaining evening on the art and science of writing scripts in PowerShell targeted especially for beginners.
Interspersed with live demos, we’ll glance through the basics such as variables, loops, and the pipeline, then briskly overview modules, remoting, a little SQL, and email control. All sample code will then be combined to solve* a “totally realistic scenario” with a Rube Goldbergian nightmare.
This is a once-off event of fun and frivolity not to be missed.
* Best practices not guaranteed.
The PowerShell Summit is the number one conference where PowerShell enthusiasts gather and learn from each other in fast-paced, knowledge packed presentations. PowerShell experts from all over the world including MVP’s, Guru’s, community leaders and PowerShell team members, will once again join together for a few days in Charlotte, North Carolina to discuss and learn how about maximizing PowerShell in the workplace. If you want to share your PowerShell expertise or story, then this is your official call to submit presentations for selection!
PowerShell Summit North America 2015 will be held April 20-22 2015 at the Microsoft Campus in Charlotte, North Carolina.
Topic Areas – What we are looking for
We are looking for 45-minute presentations covering a wide aspect of PowerShell expertise. We have two main topic areas that may assist you in building an abstract.
- PowerShell Internals – A deep look into the inside workings of PowerShell and practical solutions that are built from them. These presentations are typically more directed to the PowerShell development community that is building extensions and solutions relating to PowerShell.
- PowerShell Features Deep Dive – These presentations are a deep look into configuring and working with PowerShell features and capabilities such as Remoting, Desired State Configuration and more. These presentations tend to be more IT Pro focused.
We are open to presentations across the entire ecosystem that has been built around PowerShell; so don’t hesitate to send an abstract for your particular area of expertise. This includes Microsoft platforms and products that have PowerShell-based management tools as well as 3rd parties such as VMware.
What kind of sessions get selected?
We’re looking for sessions that go beyond – possibly way beyond – “beginner.” We look for an abstract that’s compelling and makes us salivate to see your session – so spend time writing a punchy abstract! We want sessions that offer real-world usability combined with “wow, nobody talks about THAT” awesomeness. Remember, Summit sessions are recorded, so if you’re previously presented a topic at a Summit, we’re less likely to choose it for another Summit. We want sessions that are challenging, and that ideally present things that simply aren’t explained or documented elsewhere. New modules, new techniques, and crazy approaches are all welcome. Discussion-format sessions are great, too, especially if you plan to turn them into a community deliverable (like a “best practices for writing DSC Resources” session that gets turned into a free e-guide later). Think community, deep dive, engaging, and amazing as keywords. We want attendees to finish each day with information leaking… just a little bit… out their eyeballs. Help us make it happen.
We do have some goals for speaker selection, too. We obviously have, and appreciate, the great involvement we get from the product team. We aim to have a certain number of sessions from well-known members of the community, simply because they’re well-known for a reason – they do a great job! But we also set aside slots for newcomers who’ve never presented before, or who’ve maybe only presented once or twice before. We want to create opportunities for more folks to become engaged and active in our community, and the Summit is a great way to do that.
We aren’t looking for soft-skills sessions, like “how to get a new user group running,” although contact us via email (summit@) if you’d like to do something like that as an extra evening thing after the main content wraps for the day.
How to submit abstracts of presentations
Presentations will be 45-minutes in length and the submission should include the following:
- Presentation Title
- Presentation abstract – a description of the presentation and the topics covered. 250 words or less and suitable for marketing.
- Go to http://eventmgr.azurewebsites.net/preregister/account/PSNA15/2015-NA-Speaker. Create an account.
- You can always return to http://eventmgr.azurewebsites.net/event/home/PSNA15 to login and access your abstracts.
- Click Abstracts
- Click Submit Abstract
- Provide a title and description; descriptions must be 50-250 words. Set the Status to “Ready to Review” when you are ready to send your session to us for consideration.
You can submit multiple presentations in the same topic area or for different ones. Be aware that even though the session length is 45 minutes we prefer to have at least 10 minutes set aside for questions. Summit presentations are intense and intimate often with plenty of audience interaction. Also because of the length, generally co-presenters are unnecessary, but that is not a requirement.
Presentation submission deadline – When you should send it by
Start sending your presentation submissions immediately! The selection committee will start selecting presentations as soon as they arrive so you don’t want to miss out. The last day we will accept presentation submissions will be September 15, 2014.
When you will know you’ve been selected
The selection committee will start reviewing submissions immediately and begin the selection process. You will be informed if one or more of your presentations have been selected and sent a contract on or before October 06, 2014. You will need to return the signed contract by October 31, 2014.
Selected speakers will be given free admission to the event, including attendance at all official Summit activities. However, AWPP membership is not included. Speakers may not bring guests to the event. We have a limited budget, and the number of speakers selected will be partially governed by that budget. Speakers are responsible for their own travel expenses, including hotel, airfare, and ground transportation.
The final agenda will be announced and posted on PowerShell.Org.
We look forward to your submissions and your help in making PowerShell Summit North America 2015 the most valuable IT/Dev conference of the year!
Recently on the PowerShell.org forums, a community member mentioned that they were having trouble setting up a Server 2008 R2 machine as a DSC pull server. It turns out, this is possible, but you have to install all the prerequisites yourself, since the Add-WindowsFeature DSC-Service command doesn’t do it for you on the older operating system.
Refer to this blog post for the checklist.
# List all classes in a namespace
Get-CimClass -Namespace root\CIMv2
Get-WmiObject -Namespace root\CIMv2 -List
# list all classes containing “service” in their name
Get-CimClass -Namespace root\CIMv2 | Where CimClassName -like ‘*service*’ | Sort CimClassName
Get-CimClass -Namespace root\CIMv2 -Classname *service*
Get-WmiObject -Namespace root\CIMv2 -List | Where Name -like ‘*service*’ | Sort Name
# get all class instances
Get-CimInstance -Namespace root\CIMv2 -ClassName Win32_OperatingSystem
Get-WmiObject -Namespace root\CIMv2 -Class Win32_OperatingSystem
# filter class instances
Get-CimInstance -Namespace root\CIMv2 -ClassName Win32_LogicalDisk -Filter “DriveType=3″
Get-WmiObject -Namespace root\CIMv2 -Class Win32_LogicalDisk -Filter “DriveType=3″
# show all properties
Get-CimInstance -Namespace root\CIMv2 -ClassName Win32_OperatingSystem | Get-Member
Get-WmiObject -Namespace root\CIMv2 -Class Win32_OperatingSystem | Get-Member
# show all properties and values
Get-CimInstance -Namespace root\CIMv2 -ClassName Win32_OperatingSystem | fl *
Get-WmiObject -Namespace root\CIMv2 -Class Win32_OperatingSystem | fl *
# remote computer
Get-CimInstance -Namespace root\CIMv2 -ClassName Win32_BIOS -ComputerName dc,win81
Get-WmiObject -Namespace root\CIMv2 -Class Win32_BIOS -ComputerName dc,win81
# use CIM command to talk to non-CIM computer
Get-CimInstance -Namespace root\CIMv2 -ClassName win32_BIOS -CimSession (
New-CimSession -ComputerName OLD-XP-PC -SessionOption (
New-CimSessionOption -Protocol Dcom
Trend Micro released a report on a new PowerShell-vectored exploit named Black Magic. I had a lovely Twitter conversation about what this means in terms of PowerShell’s vulnerability to attack, and what admins should do. Unfortunately Twitter sucks for carrying on that kind of conversation, so I wanted to post this to clarify a few things.
First, I’m going to write this article as if “you” were hit by this exploit. Don’t take it personally, it’s just an easier style of language for me – it’s not actually addressing you.
Second, when it comes to security, the goal is to stop attacks from happening. That means you have to consider all the ways something could nail you, and try to block as many of them as is practical. That’s called “defense in depth,” giving you multiple layers of defense. The corollary to that is that your environment must still be functional. I mean, from a secure standpoint, if I unplugged all the WiFi access points and Ethernet switches you have, you’d be pretty secure. And non-functional.
Third… and I don’t know how to be delicate about this, but a lot of admins out there aren’t very sophisticated about security. There’s sometimes a tendency to fix what they can get their hands on, whether or not that makes any impact on security or not. So let’s be very clear about what you do when it comes to security: You do as little as possible, and impinge as little functionality as possible, while achieving your security goals. That helps maintain a “functional” environment, and keeps the security aspect of it “maintainable.” Sometimes, “as little as possible” is quite a lot indeed – but you look for that balance. Finally, you almost never do anything to “improve” security if it is in fact a null improvement. That is, you don’t lock the doors if the windows can’t be closed. There’s no point.
Now, let’s look at how Black Magic operates.
Step 1: Social Engineering
The exploit comes in the form of an .LNK e-mail attachment. That’s a Windows shortcut file. Users are meant to double-click it, and the shortcut launches a PowerShell session with the execution policy essentially turned off.
Problem 1: You let users get .LNK e-mail attachments from external users. This is stupid. Users shouldn’t be able to receive executable file types. Note that a .PS1 file isn’t an executable file type, which is why the exploit had to take this action. If you’d blocked .LNK attachments at the firewall, the exploit would be useless.
Problem 2: Your users are opening file attachments from people they don’t know. There is no technical way to protect an environment where users aren’t doing the right thing. No way. Just give up. This is why I keep going on about building a “culture of security.” If your users’ job descriptions, or your company employee manual, doesn’t say something to the effect of, “employees must be able to safely operate company computers in accordance with company policies and standards,” then you’re just doomed. If it does say that, and a user does open an attachment like this, you write them up and eventually fire them. If you think you can stop stupid users from bypassing every security measure you put in place, you are dumber than they are. You have to fix the social engineering element. There is almost no point in trying anything else, because users will get around it.
I know. A lot of you are shrugging and saying, “well, you can’t fix users, so I’ll just lock down PowerShell.” It won’t work.
I once, and rather famously, refused to help a law firm client get their NTFS file permissions under control, because they let users print sensitive documents and leave them lying around the office. Don’t bother locking the door if the windows are open.
Step 2: The Download
One of the elements of the Twitter discussion was, “maybe standard users shouldn’t have PowerShell able to run, because it’s so powerful and can be exploited so easily.”
First: PowerShell’s execution policy is not a measure against malware. It was never designed to be, so don’t be disappointed when it isn’t. If you thought it was, you were wrong, and that’s your fault for not educating yourself, not Microsoft’s fault for failing to do something they never set out to do in the first place.
Second: PowerShell only lets you do what you have permission to do. The Black Magic exploit used PowerShell simply to download a file from the Internet. That’s it. It didn’t wipe out Active Directory, it didn’t erase a file server, and it didn’t start grabbing messages out of Exchange, because normal users can’t do those things.
Would locking down PowerShell, so that normal users couldn’t run it, have stopped this exploit? No, because normal users have an abundance of ways to download files, and the exploit would simply have used a different one. PowerShell was convenient here, not necessary. If you’re going to posit locking down PowerShell, you must also lock down every other possible means of downloading a file from the Internet, or you’ve done nothing to impact security. Nothing.
PowerShell is not powerful. Erase that from your mind. Everything PowerShell is and does comes from the .NET Framework installed on every one of your computers, which your users have full access to. PowerShell is nothing more than a human-friendly way of getting to the Framework without needing Visual Studio on-hand. You could erase PowerShell and 100% of its functionality would still be present and absolutely usable by an exploit. Get your brain wrapped around that, because it’s an important concept.
Problem 3: You let your users download files from trashy websites. Your firewall should have been blocking access, and if it had integrated malware tools and realtime block lists, it probably would have caught this access.
Problem 4: You’re not using a local to block outgoing access by applications. For standard users, there’s little reason to access the Internet by means other than a web browser or known applications. This is a well-known technology and approach that’s been around for a decade.
Step 3: Run a File
Black Magic’s last step is to run the downloaded payload, which it does under normal user permissions.
Problem 5: You’re allowing users to run arbitrary applications. AppLocker has been around since Windows Vista, and provides a way of “whitelisting” applications that may run. This payload would never have been allowed to execute if you’d been using a built-in tool that’s been around since 2008. AppLocker even offers the ability to build that whitelist for you.
Problem 6: You’re not running updated anti-malware software that would have detected the payload and blocked it – and alerted someone. Most would have blocked access to the URL where the payload came from, too.
So you’ve had six opportunities to stop this exploit, all of which involve well-known, years-old technologies and techniques. You probably haven’t done most of them, and so you want to blame PowerShell.
OK… I’ll step out of the “you” attack-y mode :).
The point is that, once you have arbitrary code running on users’ systems, you’re owned. Nothing you can do to PowerShell will stop that. This attack could easily have been a .LNK file that ran Cmd.exe and the Telnet or FTP client – it could have achieved the same thing. It could easily have been an .EXE (“no, we block EXE file attachments;” “why the hell don’t you also block .LNK then, dummy?”).
I don’t want to come across as defending PowerShell per se; I’m trying to help folks understand where the real security problems lie. PowerShell is a red herring in all this; it was a convenient way of getting innocuous code to execute. There were six other places where this attack would have been stopped in its tracks, and any six of those would also have stopped every other similar kind of attack that didn’t rely specifically on PowerShell. That’s what makes those six effective – they’re global, not targeted at one specific piece of code. All of those six act to stop malware.
Before you take actions in security, you need to make sure you’re doing so from a holistic, professional security perspective. The first time a fire broke out in a crowded theater, officials didn’t say, “well, we should put sprinklers and alarms in that theater.” They put them in every theater, and started demanding flame-retardant fabrics and other measures. You address security across the board, not on a piecemeal basis.
A Tangent Argument
“Ah,” the argument goes, “but we should reduce moving parts. Users don’t have a legit need to run PowerShell, so we should lock them out of it.”
Valid. Except that PowerShell.exe isn’t PowerShell. PowerShell is a .NET Framework-based engine; PowerShell.exe is just a console application that lets you feed typed commands to that engine. You can’t remove PowerShell, and you can’t “block” users’ access to it, because it’s part of the Framework. It’s an integral part of the operating system. Things you don’t even realize are using it, are using it.
But yes, you could block users’ access to the console application, PowerShell.exe. I might even buy that argument, especially in a highly secure environment where you simply don’t want users having access to anything they don’t explicitly need to do their jobs. In fact, I would buy that argument, if and only if you block users’ access to everything they don’t explicitly need. Notepad. Windows Paint. Solitaire. Etc. Because based on the theory you’re working from, all code is bad code (a valid security perspective) and you block everything not explicitly needed. Remember, PowerShell doesn’t give users any special capabilities. Anything a normal user can do in PowerShell can be done in at least 2 other ways using other native tools. This is why AppLocker is a better approach: the list of apps a user needs is smaller than the list of apps they don’t, and so a whitelist is more maintainable, no matter how huge it is.
There you go. Now, you’re welcome to make comments on this, and offer your perspective. However, I have a couple of guidelines.
- Keep the conversation civil and professional. I’ll delete anything obnoxious.
- Keep the conversation focused on security. And remember that security isn’t about locking down the doors when the windows are open; it’s about holistically achieving specific goals. You don’t take security measures that simply move the target elsewhere. “Defense in depth” doesn’t mean 80 security restrictions and 20 ways around them. If something is super-easy to bypass, you don’t bother.