Wednesday, November 25, 2015

Here is my custom Powershell prompt

Get-Help about_Prompts
    The Windows PowerShell command prompt indicates that Windows PowerShell
    is ready to run a command:

        PS C:\>

    The Windows PowerShell prompt is determined by the built-in Prompt
    function. You can customize the prompt by creating your own Prompt
    function and saving it in your Windows PowerShell profile.

One of my biggest issues with the default prompt is that I work with a lot of nested folders and network shares. It makes the path so long because the path is in there. So I change my prompt to just show the current folder and place the full path in the tittle bar.

One other thing I do is add basic command logging. I would use transcripts, but I don't want something that verbose. So I just save my last command to a text file whenever I run it.

The last thing I so is calculate where in the history the next command will be and add that to my prompt.

Here is my prompt function:

$PSLogPath = ("{0}{1}\Documents\WindowsPowerShell\log\{2:yyyyMMdd}-{3}.log" -f $env:HOMEDRIVE, $env:HOMEPATH,  (Get-Date), $PID)
Add-Content -Value "# $(Get-Date) $env:username $env:computername" -Path $PSLogPath
Add-Content -Value "# $(Get-Location)" -Path $PSLogPath

function prompt
    $LastCmd = Get-History -Count 1
        $lastId = $LastCmd.Id
        Add-Content -Value "# $($LastCmd.StartExecutionTime)" -Path $PSLogPath
        Add-Content -Value "$($LastCmd.CommandLine)" -Path $PSLogPath
        Add-Content -Value "" -Path $PSLogPath

    $nextCommand = $lastId + 1
    $currentDirectory = Split-Path (Get-Location) -Leaf
    $host.UI.RawUI.WindowTitle = Get-Location
    "$nextCommand PS:$currentDirectory>"

Monday, November 16, 2015

Powershell: Script injection with ScriptBlock.CheckRestrictedLanguage Method

I just had a post about importing hashtables from files. It basically loads the file into a script block and executes it. 

$content = Get-Content -Path $Path -Raw -ErrorAction Stop
$scriptBlock = [scriptblock]::Create($content)
$scriptBlock.CheckRestrictedLanguage([string[]]@(), [string[]]@(), $false)
Write-Output (& $scriptBlock

If that sounds dangerous, that is because it is. Your module or script my be trusted, but it may be loading files that are not trusted. This could be a stealthy way for an attacker to use your script.

I took the extra step of using $scriptBlock.CheckRestrictedLanguage([string[]]@(), [string[]]@(), $false) to make sure the hashtable is not containing Powershell commands. There is one important gotcha to be aware of with this command. The arguments are not intuitive. 

Lets take this command. Here is how the function is defined using a C# sample:

void CheckRestrictedLanguage (
        IEnumerable allowedCommands,
        IEnumerable allowedVariables,
        bool allowEnvironmentVariables

The first argument is the allowed commands and the second is the allowed variables. One could reasonably assume that a $null value for the allowed commands would mean that nothing is allowed.

If you look at my code, I create an empty string array. That may look like a very strange thing to do and I kind of agree. This is because a $null value indicates that it should allow some default commands to execute. The only way to know this one is to read the documentation very closely.

By using an empty list of strings, I do not allow any Powershell commands. When importing a hashtable, this is exactly what I want.

Sunday, November 08, 2015

Powershell: Importing hashtable from file or a psd1 file

Have you ever wanted to import a hashtable from a file? A module manifest that is saved in a *.psd1 file is a hashtable. If you ever wanted to read the meta data in it, this trick may help.

You import the contents into a script block, validate the script block, execute it and capture the resulting hashtable into a variable. Here is the sample code below:

$content = Get-Content -Path $Path -Raw -ErrorAction Stop
$scriptBlock = [scriptblock]::Create($content)
$scriptBlock.CheckRestrictedLanguage([string[]]@(), [string[]]@(), $false)
Write-Output (& $scriptBlock)

If you target a module manifest, you can access all the attributes in it. 

Name                           Value
----                           -----
Copyright                      (c) 2015 Kevin.Marquette. All rights reserved.
CompanyName                    Self
GUID                           6ab379f9-41ed-4c1e-beda-7855d1c1e3c8
Author                         Kevin.Marquette
FunctionsToExport              *
VariablesToExport              *
RootModule                     .\my_module.psm1
AliasesToExport                *
CmdletsToExport                *
ModuleVersion                  1.0.1 

The CheckRestrictedLanguage will throw an error if it finds any powershell commands in the hashtable. Because you are executing code from a un-trusted source in the middle of your script, you should validate it.

There is a second quick and dirty way to do the same thing without the validation. I almost don't want to mention it because it is so dangerous. So if you see this in the wild, know that there is a better way.

$HashTable = Invoke-Expression (Get-Content $Path -raw)

This blindly executes a file as if it was a script. This is just asking to be exploited. Think CSS cross site or SQL injection type of vulnerability. 

Monday, October 26, 2015

Using Powershell to unlock Active Directory account Unlock-ADAccount

OK, this is an easy one. There is a command in the ActiveDirectory module that already takes care of this.

Unlock-ADAccount kevmar 

So quick to type and it works so well. But unlocking the account is only part of the issue. The real question is why is it locked. If your lucky, the user will say they just miss-typed it a few times and you can let it go. Sometimes you find an account that just locks over and over. Here is a simple command that works really well in my environment to find the source of the issue:

function Get-ADAccountLockInfo
        $ComputerName = "servername",
        [pscredential] $Credential
    $WinEvent = @{
        ComputerName = $ComputerName
        FilterHashtable = @{logname='security';id=4740}
        $WinEvent.Credential = $Credential
    Get-WinEvent @WinEvent | %{
            TimeCreated  = $_.timecreated;
            Username     = $[0].value;
            ComputerName = $[1].value

Replace the server name with the name of the domain controller that is the PDC emulator. If you do not know what one that is, you can run this once for each domain controller. What it does is queries the security log for event id 4740. It then tells you who is locked at what time and where the source is.

I added a credentials option because I often execute this cross domain. The $WinEvent is a hashtable that I splat to the Get-WinEvent. That makes it easy for me to add the credential to the hashtable when if it is defined.

Any idea how to troubleshoot this with out knowing the event ID to look for? You start with the cell phone and clear any WiFi settings and emails settings. Then do the same for any tablets they have (even at home). Then exit lync and outlook on their laptop and desktop. Open 'Credential Manager' and delete all the saved credentials (do a start menu search for it). Then check all desktops and servers where they may have used RDP to connect to a session but just disconnected when they are done. Then check for services, jobs, tasks, and reporting services connections that may be using that credential.

Yeh, searching the security log is much easier.

Saturday, October 10, 2015

Powershell: how to return value from function?

Returning a value from a function is really easy in Powershell. Sometimes it is too easy if you are not careful about it. One important detail to keep in mind is that Powershell is built around placing objects on the pipe. This makes functions work differently in Powershell than it does from different languages. You are also not limited to just one return value.

Here is a minimal function:

function Test-Function
    "Hello World!"

Calling this places a string of "Hello World!" onto the pipe. You can catch it in a variable if you want or pipe it to some other command. The better way to do it is to use the Write-Output cmdlet. It makes it more clear as to what you are doing do debugging and troubleshooting become easier. 

function Test-Function
    Write-Output "Hello World!"

You can call Write-Output multiple times in a function to return multiple items. You could place it into a loop that runs 10 times and it will output 10 objects. I mention this because Powershell also supports the return keyword but it acts different. When a function gets to any return statement, it exits the function. 

function Test-Function
    return "Hello World!"

I prefer Write-Output over return but do use return when it is needed. 

I also want to mention that Write-Host is something that you see in scripts from time to time, but it is for host only output. So it is hard to capture into a variable and does not go into the pipe. In most cases, Write-Output is the better choice.

Powershell: how to call a function?

Sometimes it is the simplest thing that can be the most frustrating when learning a new language. Calling a custom function in Powershell can be one of those if you come from a different language. If you are having an issue with this, you have come to the right place. You are probably looking at something like this and wondering why it wont work:

TestFunction($Name, $Count)

If your coming from another language, this looks like it would be perfectly normal. The gotcha in Powershell is that the coma and the parenthesis are not needed here for a function call and actually mean something else. In this example it defines an array.
Before I go any further, let's define TestFunction:

function TestFunction ($name, $count)
    Write-Output "Name is '$name' and Count is '$count'"

It is a simple function that takes two parameters. While this works as a function and looks like something you know, let's do it the Powershell way:

function TestFunction
    param($name, $count)

    Write-Output "Name is '$name' and Count is '$count'"

So now we have a function that takes two arguments. The first argument is name and the second argument is count. Here are the correct ways to call that function:

TestFunction $Name $Count
TestFunction -name $Name -count $Count
TestFunction -name "Kevin" -count

Now that we know the correct way to make that call and know what the function looks like, I can explain why our initial call fails to work. Because it is the equivalent to this call:

$Array = ($Name,$Count)
TestFunction -name $Array -count $null

So you were basically creating an array that contained your two variables and passing it in as an array to the first argument. You were also leaving the second argument as a null value. Now that you see it, it looks like a silly thing to do. No wonder things were not working as you expected. 

Monday, September 28, 2015

Powershell: how to concatenate strings?

I was going to write a post on how to concatenate or join string, but the Hey, Scripting Guy! Blog already has a great write up on that.