Loading...

Hi all,

I am writing you from the PSConfAsia, where I had a session regarding PowerShell Classes with my LogFileParser. Take a look here, where I posted it officially:

https://blogs.msdn.microsoft.com/daviddasneves/2017/10/27/logfileparser-with-powershell/

All the best,

David das Neves

Premier Field Engineer, EMEA, Germany


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hi there,

take a look at my latest blog article about WaaS and clearing it up – hopefully:

https://blogs.msdn.microsoft.com/daviddasneves/2017/06/18/demystifying-windows-as-a-service-wake-up-please/

#David


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

TL;DR; (“too long; didn’t read”)

There are some people who don´t have the time to read the whole text – if you are familiar with the topic the text in bold includes the most important points and is just for you.

The most important points to enforce Powershell Security is to use the newest Versions (OS and Powershell), use whitelisting and enforcing the usage of the ConstrainedLanguageMode and establish a good rights structure with frequent centralized logging and validate all the new features coming with the new Windows 10 Versions. And now in more detail:

Hi together,

I work as Premier Field Engineer for Microsoft Germany and have been working with many enterprise customers to assist in the preparation of the migration towards Windows 10. Here I got very often asked how to establish a complete Powershell Security approach. What are the most important steps and what has to be done in which priority order? The problem is that there is no comprehensive overview for this. And the complexity also raises from 0 to 100 within the first topics. There are a lot of dependencies which you should be aware of!

Therefore I created a session for the Powershell Conference 2017 to show this in depth – unfortunately it is a huge amount of information and you need to know about some of the technical terms to understand the whole picture which I will explain within this (long) blog post.

First we should start why everyone thinks that Powershell is the evil armyknife for the blackhats out there. The news are full of security breaches where Powershell has been used. If you search a little bit you will find without any doubt dozens of hacking frameworks which can be used out of the box even from unexperienced people and allowing to do disturbing harming things much too easily. This brings most people (who are not familiar with the technical parts in depth) to the conclusion that Powershell is evil and has to be deactivated. Don´t try this. You won´t do this even correctly. Powershell can be used even without the Powershell.exe and there are some frameworks like PSAttack which do this easily as you can see in this Procmon log:

Powershell is just powerful!

As you can see in the picture Powershell is one of the most used languages on GitHub.

Hackers use Powershell for the same reasons you do. Because it is more convenient than twenty years of other popular command line tools. And how does Powershell compare to all the other scripting languages ot there? Lee Holmes did an awesome job comparing the most known ones and created different evaluation categories to compare them all. And this was the outcome:

Lee Holmes, Azure Management Security, April 10, 2017, Comparison

So – Where to start? The Powershell Version!

First of all you have to understand the basics when it comes to Powershell Security. Here we start with the most simple point – this is definetely the Powershell Version itself – and here you should target always the most current one which is out there – Powershell Version 5 (WMF 5.1)

Many customers do still use Windows 7 and are going to use it at least to a decent number for the next 2-3 years. With WMF 5.1 it is very easy to update the Powershell Version on your existing machines to it and this is also a must do for all the Windows 7 machines. I got very often tackled with arguments like “ah we are just in the uprading process to Windows 10 – we don´t touch our Windows 7 machines anymore.” – I have to be very honest here – this kind of argumentation is just – stupid. How many computers does an attacker need to initialize his attack? Correct! – only one computer.

What changes with Version 5?

Powershell Version 5 adds additional capabilities with the constrained language, the logging and brings also some improvements regarding JEA. We will speak about this later on. Just update it – it is a must do!

Powershell Version 2 – be aware of! (read here)

There are some attacks targeting the usage of the Powershell Version 2. Why? No logging. In Windows 10 you can disable the integrated Version 2 via optionalfeatures and this a important recommendation after having tested it.

Speaking about versions – what´s about the OS?

Windows 10 comes along with many security features, which we will describe later on in very detail. To give you just an overview this are the keywords you should know about: Credential Guard, Device Guard, AMSI, WDATP and much more. In a nutshell – speaking security-wise the recommendation is so easy as you can image. You should migrate to Windows 10 and evaluate all the security features which can be used.

ExecutionPolicy

There it is – the ExecutionPolicy. I cannot even describe how frustrating this topic sometimes can be. I have been at so many big enterprise customer (n clients > 20000) who used the ExecutionPolicy as a security boundary.

Please remind the following analogy:

ExecutionPolicy is like a baby door. The ExecutionPolicy keeps babies safe but every grown-up surpasses it easily.

There are like over 20 ways to surpass the ExecutionPolicy even as a standard user. Therefore you should set it via GPO as you like it. (RemoteSigned e.g.) It may prevent some people using Powershell scripts from the internet but you should not count on it.

Powershell Remoting

Powershell is evil – the only thing which is even more insecure is Powershell Remoting. True? Not even close. Take a read here.

The facts:

  • always encrypted by default
  • single port 5985 or 5986
  • PowerShell remoting respects all Windows authentication and authorization protocols.
  • It requires local Administrators group membership by default.
  • It can be even hardened with IPFilters and TLS.
  • The improvements in WMF 5.0 (or WMF 4.0 with KB3000850) make PowerShell the worst tool of choice for a hacker when you enable script block logging and system-wide transcription.
  • Hackers will leave fingerprints everywhere, unlike popular CMD utilities.

For this reason, PowerShell should be the only tool you allow for remote administration. 

You have to just set up a correct right structure in your environment and then it´s the most secure technology to do remoting.

Till here we have done our most important and most basic settings as shown in the following graph:

Important: I will use these graphs in the whole article and extend them time by time to reach a complete security approach at the end. They should be read always from the left to the right. The most important points which normally also don´t take too much invest to implement are mostly oriented to the left. The more you get into the right area – the more you increase the security level – but the effort to reach some of the goals is also higher and comes along with an higher investment of time or money by using new technologies, setting up dedicated servers or investing human resources.

Securing Privileged Access

In the last part I wrote the following sentence: “You have to just set up a correct right structure in your environment.” And this topic is completely about this. We (Microsoft) have developed a roadmap to achieve a very comprehensive approach which is separated into 3 parts:

Unfortunately this is a very huge topic. The complete approach can be found in the following link and is worth a read for every security-oriented person!

https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access

For our Powershell Security Approach it is worth a mention but this would exceed the main topic too much. To consolidate the information I created the following simplified graph.

Modernizing Environment

This is a topic which most of my customers are in. They are planning to migrate to Windows 10 with new hardware and evaluate all the new security features which came along with. Starting with the most important ones:

One of the biggest attacking vectors is Pass the Hash. There are also Powershell modules out there like mimikatz which can be used out of to box for such attacks. It can be described easily – the attacker obtains the password hashes from one machine and uses them remotely to connect to other machines and with some other techniques he tries to elevate his rights he is using. The following picture illustrates this.

Windows 10 brings this really cool new feature called Credential Guard. The hashes are stored in a separate container on which the attacker cannot read on. As simple as that. Technically spoken this is the process LSAIso (isolated). The communication is done via RPC-Calls.

In my opinion the following video just nails it:

Credential Guard on Windows 10 Enterprise - YouTube

The next part which I have put into the topic Modernizing Environment is one the most important ones speaking of Powershell Security:

Whitelisting / Signing / ConstrainedLanguage / Applocker / Device Guard

Signing allows us to set a trust in the scripts. The signing certificates can be created by our PKI environment and give even the developers security to not accidental modify and execute scripts. In combination with DeviceGuard or Applocker this can be used as a prerequirement for executing it. Only our signed scripts would then be executed in the FullLanguageMode.

FullLanguageMode?

First of all we need to get to know what the Full / ConstrainedLanguageMode is. Powershell can be used in different language modes. If you configure your ExecutionPolicy and don´t user Powershell Version 5 or AppLocker / DeviceGuard any attacker can use the FullLanguageMode. So he can load his COM objects / libraries / classes into his Powershell session as he likes to. In the example of mimikatz – he is able to load this framework and easily capture the credentials out of a Windows 7 device. ConstrainedLanguage cuts this ability down massively and breaks nearly all attacking frameworks. But how can you enforce Powershell to use the ConstrainedLanguageMode? And how do you control that some scripts still keep working and use the FullLanguageMode?

And here comes the Powershell Version into play. First of all you need the Powershell Version 5 to enforce this. Coming with Powershell Version 5 you can enforce this either with Applocker in Allow Mode or DeviceGuard using UMCI (User Mode Code Integrity).

Damn! So many technologies and dependencies. Let us first take a look at the separate technologies.

Applocker with Powershell Version 5:

The aim should be the usage of Applocker in Allow Mode. The downside of Applocker is that every admin can deactivate it by stopping the service AppIDSvc.

Scripts that are allowed by the AppLocker policy (for example: signed by the enterprise’s trusted code signing certificate, or in a trusted directory) are not subject to Constrained Language.

Device Guard (detailed information)

  • Combination of hardware + software security features
  • Enables businesses to strongly control what is allowed to run
  • Brings mobile-like security protections with support for existing line of business apps
  • UMCI places PowerShell into constrained language mode
  • Device Guard UMCI also applies code integrity rules to DLLs.

What is the whole picture for this?

Device Guard can be separated from this overview into KMCI and UMCI and you see how they come into play here. Many customer do just have Applocker in usage today. The recommendation here would be to start with Applocker leveraging towards Allow mode in combination with DeviceGuard in KMCI. Afterwards leveraging Device Guard towards UMCI.

Code Integrity + Applocker:

  • Together, AppLocker and code integrity are the two technologies for enforcing code and application rules on Windows
  • Code integrity best expresses high level expression of trust
  • AppLocker allows for granular rules
  • Managed through common management tools in Windows 10

Now we have learned a lot of new stuff – let us recap the last topic of Device Guard with Powershell Version 5:

  • Device Guard UMCI is another security feature that a defender should consider from a cost/benefit analysis.
  • It will always be vulnerable to bypasses, but raises the baseline bar of security.
  • So obviously, you would want to use additional security solutions along with Device Guard – e.g. WEF, an anti-malware solution, and to perform periodic compromise/hunt assessments. (we will dive into this little later)

The last part of the category Modernizing Environment shows our newest defense technologies.

Anti-Malware Scan Interface is an interface which can be used by every Antivirus scanner to evaluate if a script is potentially harmful.

  • AMSI enables all of the scripting engines (PowerShell, VBScript, and JScript) to request analysis of dynamic content, from a script file, typed commands at the command line, and even code downloaded and executed in memory.
  • When code is delivered to the PowerShell “engine” (System.Management.Automation.dll), it is sent to the AMSI for anti-malware checks. Windows Defender supports AMSI on Windows 10 just out of the box. 

And this is how it looks like when its working.

The next topic is the Windows Defender Advanced Threat Protection. But before we start with this extremely great feature we throw a look at the Windows 10 Defense Stack:

As you can see we have two approaches here. Everything that belongs to the Pre-Breach Approach and a second one – the Post-Brach Approach. Every good security person today knows thats not only anymore about preventing attacks. The detection of attacks increases in importance day by day. A huge number of all attacks are even processed without any malicious code. So not even the best AV on the worls can catch these attacks! Today it is crucial to have the latest updates. (You WannaCry again?)

Advanced Threat Protection 

Windows Defender ATP combines sensors built-in to the operating system with a powerful security cloud service enabling Security Operations to detect, investigate, contain, and respond to advanced attacks against their network.

Herefore the Microsoft Intelligent Security Graph is used which stores all information and creates patterns for different attacks by different hacker groups.

Gathering all the necessary information at the customer side:

You can easily view what happened and which event correlate to each other:

In this example you can see a NEROBLAZE attack and can initialize your response to this. ATP is built-in in Windows Defender – therefore you can trigger actions which normally need elevated rights. For example – cutting down network connections, shutting down processes and many more. Also you would get to know where this email with this attachment landed in your environment to proactively prevent all users to open the attachment.

Logging

Coming with Powershell Version 5 we have the additional logging capabilities of ScriptBlock-Logging. Read Here.

The problem for some customers is to store and evaluate all the logging data. But this is a topic you should be aware of as for the following recommendations:

You should actually activate all three log sources because you want to detect ongoing attacks and cannot prevent every attack. We are here again in the previously described Post-Breach Approach where we want to detect intrusions as fast as possible. Also it leverages us to do afterwards a good forensic analysis – how the hackers entered into our system and what the main targets have been. (must read)

ScriptBlockLogging

Script block logging provides the ability to log de-obfuscated PowerShell code to the event log. Most attack tools are obfuscated, often using Base64 encoding, before execution to make it more difficult to detect or identify what code actually ran. Script block logging logs the actual code delivered to the PowerShell engine before execution which is possible since the script code needs to be de-obfuscated before execution.

Since many PowerShell attacks obfuscate the attack code, it is difficult to identify what the script code does. Script block logging de-obfucates the code and logs the code that is executed. Since this code is logged, it can be alerted on when seen by a central logging system.

One key challenge with identifying offensive PowerShell code is that most of the time it is obfuscated (Base64, Base64+XOR, etc). This makes real-time analysis nearly impossible since there is no keyword to trigger alerts on.

Deep Script Block Logging records the content of the script blocks it processes as well as the generated script code at execution time.

Microsoft-provided example of obfuscated command code:

## Malware
function SuperDecrypt
{
param($script)
$bytes = [Convert]::FromBase64String($script)
## XOR “encryption”
$xorKey = 0x42
for($counter = 0; $counter -lt $bytes.Length; $counter++)
{
$bytes[$counter] = $bytes[$counter] -bxor $xorKey
}
[System.Text.Encoding]::Unicode.GetString($bytes)
}
$decrypted = SuperDecrypt “FUIwQitCNkInQm9CCkItQjFCNkJiQmVCEkI1QixCJkJlQg==”


Invoke-Expression $decrypted
Extended Logging / WEF and JEA

But with enabling the logs you didn´t win anything. You surely have to examine the content of the logs. Therefore you should evaluate between WEF and SIEM solutions. The main aim is to centralize all the log data and examine the logging data (automatically with keywords)

Just Enough Administration (read here)

JEA allows specific users to perform designated administrative tasks on designated servers without giving them full administrator rights. JEA is based on Windows PowerShell-constrained run..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hi together,

I have been asked many times how to store and use securely credentials / passwords in scripts. The simplest thing is just to create a credential on a computer and export it via Export-Clixml where you make use of the SecureString and the native Windows Data Protection API (DAPI), which is secure. (take a look here) But the downside is that you can decrypt the securestring only at the computer and with the user who encrypted it.

Therefore I want to show you this simple but neat way to achieve this task on all computers. For this we simply make use of certificates to encrypt and decrypt the passwords which you would preferably create with your own PKI and deploy with your management solution.

How does this look like? As simple as this:

Install-Module ProtectedData

#Testing purpose
New-SelfSignedCertificate -Subject PowershellSec -KeyUsage KeyEncipherment -CertStoreLocation Cert:\CurrentUser\My 

#Retrieving cert
$Cert = Get-ChildItem Cert:\CurrentUser\My | Where-Object {$_.Subject -like '*PowershellSec*'}

#Production
#$Cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like 'CN=PowerShell Automation*'}

# Encrypt password and store it in a file.
Protect-Data 'Password' -Certificate $Cert | Export-Clixml .\encrypted.xml

# Decrypt password from file within script.
$PasswordToUse = Unprotect-Data (Import-Clixml .\encrypted.xml) -Certificate $Cert 

$PasswordToUse

Alternatively you could also just use the Powershell built-in cmdlets:
Protect-CmsMessage and Unprotect-CmsMessage

Happy using!

David


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hi there !

And again – a fantastic Powershell Conference managed by Tobias Weltner is now over!

The session materials can be found here:

https://github.com/psconfeu/2017

The video material can be found here:

powershell.video

Additionally to this I will create also some blog posts to my sessions. In one of these I will explain Powershell Security in depth! Stay tuned!

David


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This was kinda surprising! Thanks goes to Anuj.


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Powershell on GitHub – collaborate! https://github.com/powershell


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

2017 New Years #PowerShell #DevOps Study List http://ow.ly/uLjF307qoO8 Release Pipeline Model. http://ow.ly/i/qg0IQ


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Here we are – speaking about a topic, which all companies should have discussed and implemented years ago, but most of them didn´t. I will show you with some examples, why you should change your mind and even if you´re on the right train – there are still ways to improve.

Why scripting

Most of the companies think of scripting and automation as of cryptic hieroglyphics, which only the software developer gurus can handle. This is just a self protecting lie to be not forced to learn something new. Scripting (totally equally, which language you are using) is built up logically, which every IT-Administrator or IT- adept person can learn and master. But if you are still in doubt with this thesis you should take a look at the pros of scripting:

  • scripting saves time (money) – i have seen support desks improving by over 1000% efficiency by automating the tasks with scripting
  • scripting reduces human errors – you create automations, where the values are prefilled or filled automatically or even prove the entered arguments before firing up the following tasks
  • scripting reduces the requirement of GUIs – the perfect example for this is the Windows Server 2016 with and without GUI. Je – the performance without a GUI is much faster than with, but the most important underlying argument is the topic security. The Windows Server without GUI needs much less to be patched then with, which is totally obvious, if you think about it. Therefore you could say, that a OS without GUI is much more secure. Every time.
  • scripting creates standardization – well – it should create it. This step depends on, if you´re doing it right. With standardization you achieve a higher quality and you can reuse your code for different use-cases.
  • scripting enables new technologies – this is a point i will show later on in the Powershell part – there are lots of cool new features integrate and still new ones getting planned.
  • scripting is necessary for new technologies – Jep – you have read it correctly. There are lots of technologies coming and already on the market, which cannot be handled all over an UI: Azure / O365 / Nano Servers / the IOT topic and many more.

So, just to be honest – if you have read it up till here and you´re still not convinced, you are free to discuss your doubts or concerns with my, but a fact is, that you are on the wrong way.

Why Powershell?

  • Powershell is easy to learn. You will not become a Powershell Guru within a week, but if you start correctly, you will improve your skills successive and write your own scripts in less than half a year and will also be able to read and understand scripts within some weeks or even days.
  • Powershell works on nearly every computer. Powershell has been made open sourced previously and has now the full support also in Linux. It becomes more and more a allround scripting language, which is very powerful.
  • Powershell enables great technologies. You have to take a look at Just Enough Administration – a framework by which you can centralized delegate rights to your users without the need, that these rights belong directly to them. The next topic on your list should also be Desired State Configuration, by which you can set up and configure your servers and computers with pre or self-created templates. In the newest released Powershell Version 5 you even get the possibility to work with Classes to nearly close the gap to “real software developing”. And these are just a few.
  • Powershell is secure – In fact this is a point, which many people do not know. By not knowing how Powershell really works, what ExecutionPolicy is and how PSRemoting can be managed securely, some companies just turn Powershell off. This is actually a big mistake. (read here for further details)

Technical introduction:

Powershell is built up fully standardized. The commandlets have the same layout every time.

Verb-Noun

And there is also a list of allowed and usable verbs to improve the standardization in the names by itself. By this you know, if the command starts with “Get”, that it returns an filled object of the following Noun.

For example: Get-Command – with this cmdlet you can search any commandlet, which is retrievable und usable on your computer. But how to use it?

Get-Help – gives you all the information you need to know and most of the time this help comes with very useful examples.

One of the most important things to know and to understand is, that Powershell is a object oriented programming language with the underlying .Net-Framework, which gives any object methods and properties out of the box. Therefore the following command must by in your starting repertoire.

Get-Member – With this you can retrieve the object type of any object and also see what methods and properties it offers.

Afterwards you have to understand, how the Pipeline works and you are ready to work with Powershell.

Most of the people try to find the necessary scripts in the internet – and they will find a lot. The problem often is, if you don´t understand how Powershell basically works, you will get lots of headaches at the moment, when you are confronting the first little problems or the script does not work as expected.

Recommendation: Learn the Powershell basics before downloading and using advanced complete scripts.

Doing it the right way:

As previously mentioned, there are some things you should know. First of all

  • Use PowerShell Best Practices and Style Guide (take a look here) – standardization is important and in scripts, which are used in an enterprise companies, even more. A great tool, which may help you in the first steps is the ISE-Addon ISESteroids, which allows you to fully scan and automatically correct your whole scripts.
  • Create reusable, tested, signed and documented code – i would say, that this falls also under Best Practices, but the importance of this is so high to be solely pointed out. You should create tested and documented commandlets with help-files, which you then unite into modules. This modules then can be centralised and updated easily.
  • Centralize your knowledge / your script – i have spoken at the PSConfAsia about a centralised PSRepo-Server. The problem in a big IT-company is, that you have a lot of good people creating good scripts, which are not centralised and you are loosing a lot of knowledge transfer and also knowledge by itself. (take a look here) By respecting the previous point and creating good modules you can then store them to an internal repository to manage and distribute the code centralised.
  • Collaborate and keep up to date – Today we are living in a world of change. You have to stay up to date in the IT – even more now than some years before. Therefore take a look at the free trainings in the internet (Microsoft Virtual Academy and so on) and the videos of the conferences and try also to meet with other Powershell people at UserGroups. (German one here and here) You are also welcome to contribute to the source code itself and take a look at the upcoming versions. (here)

If you stick to these recommendations you will create powerful code bases, which will save you a lot of time in the future and raise up your quality. It is obvious in some environments, that scripting is totally necessary. The best example is the support desk. Automation of repetitive tasks is the most clear use case, which every person understands. So if you find any repetitive tasks in your business you should think a second, if these could not be automated by any kind. Sometimes the needed work to automate these tasks are not worth the work – but by my experience – these cases will be very very rare.

Thank you for reading my whole post. I hope you have taken some new information out of it and i hopefully accomplished to show you the importance of this topic. Provide me with any feedback, if you like to or get in touch with me, if you want to discuss some of the topics.

Best regards,

David


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview