{"id":2123,"date":"2015-12-01T00:00:00","date_gmt":"2015-12-01T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/powershell-day-to-day-sysadmin-tasks-securing-scripts\/"},"modified":"2018-05-01T07:57:14","modified_gmt":"2018-05-01T07:57:14","slug":"powershell-day-to-day-sysadmin-tasks-securing-scripts","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/sysadmin\/powershell\/powershell-day-to-day-sysadmin-tasks-securing-scripts\/","title":{"rendered":"PowerShell Day-to-Day SysAdmin Tasks: Securing Scripts"},"content":{"rendered":"

The series so far:<\/h4>\n
    \n
  1. Automating Day-to-Day PowerShell Admin Tasks \u2013 Part 1: Jobs and Workflow<\/a><\/li>\n
  2. PowerShell Day-to-Day Admin Tasks \u2013 Part 2: WMI, CIM and PSWA<\/a><\/li>\n
  3. PowerShell Day-to-Day Admin Tasks \u2013 Part 3: Monitoring Performance<\/a><\/li>\n
  4. PowerShell Day-to-Day Admin Tasks \u2013 Part 4: Securing Scripts<\/a><\/li>\n
  5. PowerShell Day-to-Day Admin Tasks \u2013 Part 5: Events and Monitoring<\/li>\n
  6. PowerShell Day-to-Day Admin Tasks - Part 6: Real Time IT Dashboard<\/a><\/li>\n<\/ol>\n\n

    Overview<\/h1>\n

    Scripting shells can be one of the most effective attack points of an operating system. They offer an advantage to an attacker by providing a layer of abstraction that anti-virus applications have no idea how to interpret. PowerShell is a scripting shell, but it uses ‘defense in depth’ meaning that it takes a number of approaches to preventing malicious use of PowerShell or your scripts. One of the most effective measures is to use Digital Signatures to determine whether a script is to be ‘trusted’.<\/p>\n

    PowerShell, by default, has an execution policy that prevents scripts being run at all and only allows interactive use of PowerShell. Many admins switch to an unrestricted policy, which is leaves the possibility of malicious attack wide-open, thereby risking harm for them and the firm for which they work. In this article, I will argue that using signed scripts a via digital Signatures (allsigned<\/strong>) is the best execution policy.<\/p>\n

    PowerShell is unique amongst shells in that it executes scripts on start-up. There are user or system scripts that are run unnoticed when you start up PowerShell in order to provide the PowerShell ‘environment’, and to maintain profiles for users. An attacker needs only add code to a profile is then executed using the ID of the user, along with all its permissions. It could then execute an external binary, or more covertly, load shellcode or a malicious DLL. When the user executes the script, he inadvertently executes the added code. The attacker has avoided having to load an external malicious script and the modification could easily remain unnoticed. Obviously, the PowerShell profile scripts are stored within a windows users’ directory so they may not seem to be easy for an intruder to alter, but any malware is likely to run under the users ID anyway so this, by itself, offers little protection. Digital signatures provide a measure of security wherever the PowerShell scripts are stored, and allow admins to safely share common libraries of scripts.<\/p>\n

    In case you are unfamiliar with profiles, I’ll show how you can obtain PowerShell’s environment when personalising your profile. Then I shall build on this to show how PowerShell handles this security aspect. Most important, I’d like to demonstrate that ease-of-use does not mean lack of security.<\/p>\n

    The customisation of your work environment<\/h3>\n

    The PowerShell is capable of saving time with your tasks and assisting with your work. A profile can, among other things, help with the administrator’s task. Anyone, for example, who does administrative tasks will find that many actions are performed several times per day, or each time they connect to their machine. Let’s take a simple example: you launch a remote connection on a server to update a component. How many times will you ask yourself the following question: ‘Am I really connected to server “SRV01”?’ To reassure ourselves, we open a PowerShell console and type ‘$env:COMPUTERNAME’.It is certainly wise to double-check but, in doing so, you have just lost a few seconds. You’d probably have other information you’d want to check, such as the User_AD you are logged-in as, and the up-time of the machine you’re logged into. There are, of course, tools available to provide this sort of information such as BGInfo (download: https:\/\/technet.microsoft.com\/en-us\/sysinternals\/bginfo.aspx<\/a>). Sadly it is not always possible to execute this type of tool on critical servers. It is here that PowerShell can help you if we create a profile.<\/p>\n

    To determine if you already possess a PowerShell profile, type in the following on your machine:<\/p>\n

      PS> Test-path $profile <\/pre>\n
    If the result is TRUE, then a profile has already been created. Otherwise we would need to type in the following to create the path.<\/p>\n
     PS> New-item -type file -force $profile  <\/pre>\n
    A file ‘Microsoft.PowerShell_profile.ps1’<\/strong> will have been created in the following list:<\/p>\n
    C:\\Users\\<username>\\Documents\\WindowsPowerShell\\<\/strong><\/p>\n
    This file is called a ‘PowerShell profile’, and will automatically execute its contents each time a console is opened. This file may contain personalised aliases, PSDrives, snap-ins or any other command that you judge to be useful. Database Administrators, for example, use SQLPS so much they’d want to include this in their profile, and Exchange\/Office Administrators might want the Exchange Management Shell snap-in or Azure Active Directory Module.<\/p>\n
    There are four different profiles:<\/p>\n
    PS> $PROFILE | Get-Member -MemberType noteproperty | format-list <\/pre>\n
    \u00a0<\/p>\n
    Figure 1 – List $Profile properties<\/p>\n
    Note: The term ‘User’ refers to the actual user connected to the machine.<\/p>\n
    The term ‘Host’ refers to the host application that interfaces with the PowerShell engine. (A few examples of ‘Host’: the PowerShell console, PowerShell ISE, PowerGUI).<\/p>\n
    This means that it is possible to have four different profiles for a single ‘Host’:<\/p>\n