Powershell/DSQuery attack

During some recent basic pen testing on out live XenApp 6.5 environment i happened upon an interesting discovery, essentially our desktop management software (RES) could be circumvented from a Powershell session simply by making the exe available to the user. I copied the executable from my local system to a network drive which i could access and launch from within Citrix.

This got me thinking about powershell based attack methods. With a little searching i turned up this interesting video posted on YouTube by David Hoelzer: http://www.youtube.com/watch?v=XpHgSHQZNpU

Now, in my scenario David's script would not work. I made the DSQuery exe, dll and DSGet.exe available by copying to the same network location as i had been able to launch Powershell from but DSGet would not function. However, DSQuery worked as expected. This set me about looking to use DSQuery to achieve the same result using a slightly different script.

First problem, powershell's execution policy would not allow me to run a ps1 script. I bypassed this by starting a powershell with the attribute "-ExecutionPolicy Bypass"

PS > .\powershell.exe -ExecutionPolicy Bypass

I then constructed my slightly modified script which uses only features of DSQuery.

.\dsquery.exe user -o samid -limit 0 > users
foreach ($samid in Get-Content .\users)
{
    Write-Host $samid
    foreach ($password in Get-Content ./password.txt)
    {
        .\dsquery.exe user -samid $samid -u $samid -p $password 2>> $null
        if($?) {
            $str = "Account: $samid $password"
            $str | Out-File checked.txt -append
        }
    }
}

I then created my password file. A simple list of passwords i wanted to attempt against each account that was returned from the directory query. Being conscious that i didn't want to trigger our account lockout attempts i opted to only attempt two basic passwords.

password
companyname

I executed the script from a test account with nothing more than Domain User privs and out popped my results to checked.txt file.

Amazingly (but unsurprisingly), it returned 3 accounts with with the password {companyname} but none with the password password. Good users, well done....

The biggest concern here really is that we can gather a list of all usernames on the domain from any user account which gives us a good angle to brute force our way to a higher privilege level account if we have guessed our way onto the network with say a training or test account.

Additionally, I thought this was quite an interesting query.

 .\dsquery.exe * -filter "(objectClass=Person)" -limit 0 -attr SAMAccountName Description

 Because this will expose any passwords that lazy admins have left in the description field in AD against the username. Yes, i did discover some very worrying accounts with this, namely an account setup for suppliers with SQL admin privs.