Lateral Movement with PowerShell

Editor's Notes

• #2 Welcome to PowerShell Shenanigans, or more appropriately named, lateral movement with PowerShell.
• #3 So just to quickly introduce myself to you all. My name is Kieran Jacobsen, I just moved down to Melbourne from Brisbane to take up a role as a Technical Lead with Readify. Previous to this, my background was in managaged services and financial services providers where I worked in roles ranging from sys admin to solution architecture responsibilities. I have presented at several conferences and run the poshsecurity.com blog where I cover PowerShell, automation, security and architecture.
• #4 So what will I be covering tonight? I will be starting with a discussion of PowerShell as an attack platform, look at some real world malware examples, discuss PowerShell Remoting, take a look at how Microsoft secures PowerShell, how we can bypass those defences and finally, how we can defend against some of the things we have seen.
• #5 To see how PowerShell can be put to mischievous use, I am going to run through a simple real world example. This example is based upon a simple hacker challenge that I was given by a friend a few years ago. We have a corporate environment, with a workstation, a domain controller and a firewall, an attacker will convince an end user to open a malicious excel document, and from there, escalates privilege, takes over a domain controller and finally, extracts the password hashes from the active directory database. This corporate like environment contains many of the mistakes that you will find in any other corporate environment. Group policy has never been fully utilised, only the default policies are in place, users thankfully have UAC enabled, but they are still local administrators. We also have another common mistake, a management service which runs as a active directory user, and unfortunately, its domain admin. Before you laugh, this is a disturbingly common thing to happen. As with a lot of new environments, Windows Defender is protecting us all. The firewall is something to note, it only allows HTTP and HTTPS out, and DNS from the domain controller. The rest of its config are the defaults. One last challenge has been thrown in. Use PowerShell where possible.
• #6 There are a number of incredibly obvious reasons why PowerShell makes an excellent attack platform. Code is easy to develop, modify and retarget attacks based upon changing situations. PowerShell is deeply integrated with Windows, with integration points through out the Microsoft product stack. This integration allows our malicious code to integrate with a significant portion of our corporate environment. Next, look at execution, Microsoft has developed to PowerShell as a platform to automate management tasks across an enterprise environment. The ability to run code remotely on any number of machines for system administration also gives us the ability to execute malicious code on any number of machines on your network. I hate to say it, but PowerShell has been a system default since, dear I say it, Windows Vista. PowerShell is now probably more prevalent in our enterprise environments than Java and Adobe Acrobat reader and flash, products long abused by malicious actors. If powershell is there with such a prevalence, why wouldn’t an attacker use it? What about our AV? Maybe they can protect us, well, the answer is they really don’t check for malicious PowerShell code. They are aware of a couple of malicious scripts, but they really haven’t started looking at the code like they have previously with VBScript. Symantec has stated to detect parts of the PowerSploit toolkit, but only when it is saved to the file system.
• #7 I first presented on the use of PowerShell as an attack platform back in 2012, and even when I revisited this earlier last year, there hadn’t been any real world examples. Things have changed in the past 12 months. There are two notable cases, PowerWorm, and PoshCoder. Towards the end of March, TrendMicro posted up information about some PowerShell code they had discovered. It was a trivially simple worm, which just infecting Word and Excel documents. Trend didn’t post much more than that, however Matt Graber who is the lead developer of PowerSploit, managed to get a copy of the code, and has performed an amazing analysis of the code and has also rewritten portions of the code and made them available. There is a link at the end to his write up. A few weeks after the write up by Matt, there were a number of posts on BleepingComputer.com discussing a piece of code called Poshcoder. Looking at the thread, there was a number of things that sent up interesting flags. Firstly, it appeared the developer or the maintainer of the code was posting along side the victims, which is certainly something you don’t expect to see. Secondly, there were a number of elements similar to PowerWorm, including a Word and Excel propagation method. Next, PoshCoder performs a CryptoLocker style attack, encrypting user files and extorting a bitcoin out of the users if they want to see their files back. Unfortunately, whilst the worm continues to propagate, the server where their keys should be is down, so their files are gone. Finally, and this is the important bit, everything is done in PowerShell. PowerShell malware is a very real threat. Whilst right now, the recorded instances are pretty harmless, they are becoming more dangerous.
• #8 So I made a little script, I suppose it could be called malware, which will run on a system and allow you to have remote control over the system. If I have time, I will show you, but I am not going to go into specifics today as the code will be put up onto GitHub for you to take a look. The script is cleverly called SystemInformation.ps1, in the hope users and administrators don’t work out what it is. The script will be setup to run as a scheduled task, running as local system, every 5 minutes. There is a number of different ways we could manage to set this up, in the demo it will be occurring through an Excel macro, however you could use almost anything, as long as the script is downloaded, and the task is created. When the script executes, it will do a few things. Firstly, it will collect system information and some poorly secured credentials, it also connects to the command and control infrastructure and downloads a list of tasks to execute. Tasks can be any valid PowerShell expression, a PowerShell expression, an executable, as long as it is a valid expression. Tasks, if successfully executed will only be run once, they can also be limited to executing on a single PC.
• #10 So there have been some interesting changes in terms of security with the introduction of Windows PowerShell Remoting, and WinRM. PowerShell remoting allows us to remotely execute PowerShell code on one or more remote systems, based upon the WinRM or Windows Remote Management Interface. WinRM is based upon the WS-Management protocol. Remoting gives administrators a number of execution options, firstly, a large number of powershell commands have been extended to allow for their execution against remote devices directly. Next administrators can also run a powershell script block remotely, in an experience much like rexec or using ssh to run a remote command. Finally, administrators could start a remote session, much like connecting into a full blown ssh session. Security for WinRM is governed by two things, firstly, clients can only connect to devices they trust, which can be manually configured in workgroups, or in domain joined environments, clients trust everything. User’s need the appropriate credentials, typically local admin. Finally there are some authentication protocol specifications, but they typically aren’t a huge issue. Now for the kicker of it all. Windows Server 2012, and 2012R2 introduces a new unified Windows Server Manager, trumpeted by Microsoft as an advancement of server administration, it introduces a critical flaw. Server Manager uses PowerShell and PowerShell Remoting. Microsoft made the wonderfully helpful decision to setup, configure WinRM for you, by default when you install Windows Server 2012 R1 and R2. That’s right, on by default. After years of them telling us, pretty much yelling off by default, something is now on by default. It gets worse folks, the windows firewall permits the incoming connections on all network profiles, even public!
• #12 So what security features exist in PowerShell? Well things start with the typical Windows security design pattern. Administrative rights and UAC will govern what we can and cannot do. If we needed admin rights to right to that file or registry key, or if we needed specific active directory permissions, the same will go when we run under PowerShell. We are all aware of signing executables and Authenticode, and we can extend this to signing our scripts, CMDLets and modules. This will only allow us to validate the integrity of the these files, and the identity of those who wrote the code. If a script is signed and comes from an untrusted source, you will receive an error and it will not execute. If you try to run that script and it has been modified, the same thing will occur. Unfortunately, all the usual vulnerabilities in Windows, Authenticode, Certificates and Certificate Authorities reduce the effectiveness of these controls. I really do hope that Microsoft shows some leadership and comes up with some solutions in this space. PowerShell does have one interesting security feature, something that was picked up from Internet Explorer. PowerShell will look at the NTFS zone.identifier alternate data stream to determine the source for a script or module . This allows PowerShell to make some interesting decisions about if a script should be executed, dependant upon where it came from and leads into the next feature, the Execution Policy. The PowerShell execution policy combines the code signing support, and the zone identification information to allow an administrator to control what scripts execute. Whilst it is a common assumption that the execution policy is Microsoft’s attempt to prevent malicious code, it actually more like the safety on a loaded gun. The execution policy is there to ensure you and your users that you don’t shoot yourself in the foot. There are a number of different states to this policy, and we can control the policy at a process, user and computer level. Let’s take a quick look at the execution policy.
• #13 So the execution policy consists of 6 different levels. The first is unrestricted, this is our least secure state, or as I like to call it, free for all mode. Any script, no matter where it came from. Next is remote signed, now we are becoming a bit more restrictive. If a script comes from the local pc, then we will execute it, however, a script from the internet must be signed by a trusted certificate for it to be executed. The third is all signed. With all signed, no script, no matter where it is from will be allowed to be executed, unless it has been signed by a trusted certificate. Restricted in the most, well, restrictive state. In restricted, no script, not matter where it is from, is allowed to executed, none, nothing. There are two special states, undefined, which is the policy if none has been set, this actually defaults to the restricted policy, and finally bypass, which is primarily used when calling PowerShell scripts from applications, in bypass the policy processer is, well, bypassed. This turns off a number of So, you are probably thinking, well this looks like decent security…what if I told you, I can get a script to run, no matter the execution policy specified?
• #14 So how do we bypass the policy? Well according to some sources, there are 15 different ways, these can be simplified down to 5 ways which I recommend. The first way, is to ask PowerShell to use a different execution policy for a specific powershell.exe process. Next, if we can remove the zone identifier from the file in question, PowerShell includes a friendly CMDLet to do that one as well. Another effective method, read in the file and then read it in. There are a bunch of effective ways of thing this, reading the script and piping it into powershell.exe, downloading the file, etc. A surprising method is to encode the script to base64 and then use the –encodedcommand parameter. The best thing with this one, it also bypasses the execution policy! I am going to say this. Whilst administrators are probably setting one of these levels for their workstations, they probably are not doing this on their servers. Pretty much ever server I come across, will have the policy of unrestricted. I would almost bet that there is one in everyone's windows server environment.
• #16 So how do we protect our environments from malicious actors? What defences against the dark arts exist? Defence has to be one of the more interesting challenges, and can create debate the likes of which I haven’t seen since watching debates over which was better, EMACS or VIM. The most effective method to restrict lateral movement and control who does what with PowerShell is the use of what is called Restricted or Constrained Endpoints. Simply put, we are creating a limited PowerShell session where we can only execute a limited number of commands. A great example of would be to create an endpoint where we can only run simple get CMDLets and ping. If an attacker were to gain access to this, we might effectively limit what an attacker could do, but you need to remember, those limiters could impact you and your fellow developers and administrators. Developing restricted endpoints can take a significant amount of time and effort, but the rewards can be significant. On the WinRM front, there are a number of ways we can control which systems are allowed to connect to it. Lets start with the simple. If you do not need WinRM, then turn it off. Remote Desktop is disabled on all systems by default and we wouldn’t turn it on unless we needed it, this goes for a bunch of other services and features. If you are not remotely managing systems with WinRM, then turn it off. If you do need it, then there are three recommendations I have for you. Firstly, you can configure WinRM to only respond to connections from a specific IP address or subnet, this is your first layer of defence. Secondly, setup the Windows Firewall to limit connections to these same subnets. Finally, configure your network segmentation to control access to WinRM as well. A multi layered approach will ensure that there is sufficient safeguards in place in case we have a misconfiguration. One thing to point out, there are a significant number of environments with WinRM using HTTP and not HTTPS. Please ensure that you use HTTPS. This is the sort of management traffic that shouldn’t be going over plain text. Lastly, Application Whitelisting is another good defence against any malicious code, I cannot emphasise the value of whitelisting.