Projects Publications Brandon

Monday, October 05, 2015

DotNet's DNVM for Persistence on Developer Machines

By With
One of the best resources for persistence mechanisms is Hexacorn's blog.

If you haven't checked out his "Beyond good ol' Run key" (linked above) 32 post series, you really should. But today I wanted to talk about one that I didn't see up there:

DNVM ( is the DotNet Version Manager and it's a part of ASP.NET 5, which I believe has been inside of Visual Studio since the 2013 version. It's there to help to specify which runtime to use for applications, much like RVM (Ruby Version Manager) is for Ruby. With their goal being that you can install .Net and run .Net applications on Linux and Mac as well using DNVM.

Once installed it adds a "DNX_HOME" environmental variable:

 Inside the folder specified are 3 directories:

There are plenty of things to play with in here, but I wanted to specifically point out that the BIN directory is put into the $PATH variable (as well as two others)

C:\WINDOWS\system32\config\systemprofile\.dnx\bin (DOES NOT EXIST BY DEFAULT)
C:\Program Files\Microsoft DNX\Dnvm\

Ok, not a big deal right? Even a user under UAC can edit their own $PATH variable (we'll come back to that in another post)

Lets take a look at what is in those folders:

Interesting, why don't we see what the command dnvm does:

Seriously... I probably don't even have to continue at this point...

But, if I run dnvm from the command prompt (as a developer would) it runs it from inside that protected directory in Program Files right?... RIGHT?! Nope..

Edit the dnvm.cmd with a bit of PowerShell Empire stager (minus the -W Hidden, because we need the user to actually get the output of the dnvm command) and....

[+] Initial agent UU2YKZ3VDG2AUKFY from now active


Lets look a bit into how DNVM works to see if there is something juicier there (way to much for a single blog post)

Awesome! So I can modify things in the runtime directory, lets look in there:

Lots, of fun, but we still have to wait until they run some C# code with that run time and guess which one they will use (or backdoor all of them). I would rather just make a modification to the dnvm.cmd and be done with it. Simple and clean.

Oh did I mention that this is used to cross compile binaries? Ya, oh ok, so you can infect the built binaries, or web apps for Windows, Linux and OSX...

Oh and one other thing caught my eye while I was looking into the DNVM.ps1 script:

Have fun!

P.S. Unquoted paths FTW:
Read More

Thursday, October 01, 2015

Hiding desktop icons for presentations on OSX

By With
If you found this post via a search, you are probably like me, "not great" at keeping your desktop clear "stuff" (you probably have a 'stuff' folder you once put stuff in and forgot about). 

If you are, and you go into a presentation, you probably don't want to have all of your icons visible (and possibly recorded).  Hiding your desktop icons on Windows (since 7 I believe) is pretty simple. 

On OSX, its not as straight forward. Following a tip I found here: I was able to create a keyboard shortcut to hide, or unshide everything.

First, open up "Automator" and create a new document / "Service" 

Then drag and drop "Run AppleScript" from the Utilities section:

Next, make sure it says that the service doesn't accept input from any application:

Paste in the following script:

on run {input, parameters}
set myAnswer to (do shell script "defaults read CreateDesktop") as boolean
do shell script "defaults write CreateDesktop " & ((not myAnswer) as string)
do shell script "killall Finder"
end run

On the first run, you may get an error stating that the variable doesn't exist or that it couldn't convert it into a boolen. This is because by default this variable doesn't exist for new users. All you have to do to correct this is open a terminal and type:

defaults write CreateDesktop true

To set it for the first time:
Back in Automator, re-do the test run of the script:

Save the file and then you can setup up a keyboard shortcut in System Preferences:

Hit Control+Cmd+H to your hearts content. 

Read More

Thursday, September 24, 2015

Hacking Advice for @krystropolis

By With
Today I was asked by @Krystropolis for a "Hello" and maybe some hacking advice, see tweet:

I thought about it on my entire 1 hour drive home from just turning in my badge and laptop from a big corporation to go work at a start up. I thought about talking about ethics and data handling, to Geo-politics. I mean, what kind of hacking are we talking about.

I finally ended up thinking about what would have been the best advice for me, growing up, for "how to learn hacking", and I boiled it down right before I pulled into my drive way to two words: "Build It". For me personally, I didn't start to really understand attackers, attacks, or even simple defense strategies until I started to try to build it myself.

For many hackers (and mechanics, my father included) they started by taking things a part first, then putting them back together (usually with a few extra screws or parts that "didn't matter" on the side). But for me, I learned best, by building from scratch. This went from stealing RAM for the "old junk" computer locker from my high school to upgrade my Mom's 95 Mhz Pentium (OH YA!) - in my defense, the computer science teacher told me that I could take anything I needed to build a computer and he didn't specify the physical location that computer had to be in - all the way to working on the sensor grid for the Marine Corps networks when I helped at the MARCERT as a level 1 tech. I even convinced a few of the Hak5 crew at the time to let me build Gentoo (Stage 3 baby!) on their laptops because it was tons faster (once everything compiled 10 years later).

Man do I ramble. Point is. If you want to learn hacking, or how to hack, you need to know a system inside and out first. System (noun) in it's most basic sense. The best penetration testers / hackers I have ever known are the ones that have rebuilt their labs/phone/widget for the 500th time.

UPDATE: I have had a few comments, about the post already. But what I forgot to point out is that by building a system or network you not only get to know the ins and outs of how it works, and what shortcuts you had to take to get it to actually work, but also the appreciation of what it took for you to build it, the hours/research that went into it, how it connects to other systems and clients, and finally what kind of business impact it could or does have on actual corporations. These are core skills to be an effective communicator of risk and need, while keeping compassion for the requirements and business impact. Highly sought after skills in the job market.

I hope this helps.
Read More

Wednesday, September 16, 2015

Get PasswordLastSet time for Domain Controller accounts

By With

Yesterday I posted a way to dump hashes using a Domain Controller account. But how do you know which account to use? And when was it's password last set? net user unfortunately won't do computer accounts.

So I decided to write a PowerShell script to find out. Unfortunately Windows 7 doesn't come with the ActiveDirectory PowerShell module (I'm sure there is another way to do this but here is how I did it.

Installed the Remote Server Administration Tools - (Not stealthy)

Then I was able to use the follow janky script I wrote to find all of the PasswordLastSet values for all of the Domain Controllers

Import-Module ActiveDirectory

$dclist = Get-ADDomainController -Filter { isGlobalCatalog -eq $true } | Select-Object Name

Foreach ($dc in $dclist)
    $lastset = Get-ADComputer $dc.Name -property PasswordLastSet
    Write-Host "$($dc.Name) - $($lastset.PasswordLastSet)" 

This would probably be an awesome recon / situational awareness module for Empire ( ) but written better hopefully.

Output is pretty simple, it looks like this:

DC1 - 09/15/2015 07:05:40

Now I know that I have about 29 days left of valid use of that hash.
Read More

Tuesday, September 15, 2015

Using Domain Controller Account Passwords to HashDump Domains

By With
Since I follow both +Carlos Perez and +Benjamin Delpy on Twitter, something caught my eye on August 2nd, soon after +Benjamin Delpy drops DCSync:

And then later on August 28th, again about the DC$ account (Domain Controller computer account):

Because DCSync is calling on "sync" based APIs of Active Directory, that are, by default, used only by Domain Controllers, all Domain Controller computer accounts would have the ability to do this as well as the Domain/Enterprise Admins.

Anyone who's ever administered an Active Directory, knows that computer accounts change their passwords automatically. How often do they change them?
Machine account passwords are regularly changed for security purposes. By default, on Windows NT-based computers, the machine account password automatically changes every seven days. Starting with Windows 2000-based computers, the machine account password automatically changes every
30 days
PSSSST!! That article is about how to DISABLE automatic password changing

Alright. So, I'm not going to go into "how" to get the hashes for a computer account, but if you've ever dumped passwords before, the computer accounts are the ones with the "$" on the end. Find the ones that are domain controllers, match up the hashes, and use Impacket's to your heart's content. (Or until the password changes for that DC, then you use another one to dump it again, oh, did I not mention that computers don't change their passwords all at the same time in that 30 day window?)

Remember, Domain Controller's don't have a lot of other permissions, so you need to use the "-just-dc" option in SecretsDump in order for it to just do the domain dump:

python -hashes aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 -just-dc LAB/DC2k8_1\$@

Impacket v0.9.14-dev - Copyright 2002-2015 Core Security Technologies

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets

Happy #HackersDay

Read More

Monday, September 14, 2015

2015 DerbyCon Hiring

By With

It’s often tough from both hiring and job hunters to find one another at conferences. I think this is mostly because of a couple things.

  1. No one wants to stand at a both on either side and talk job stuff in front of a bunch of people and people at booths rarely get the chance to get away.
  2. It’s hard to know “who” to talk to.

So I created a very simple Google doc to help put twitter handles and links together for people who are job hunting and people who are hiring to kinda get to know who to talk to.

Got more to add? Please let me know and I’ll get it added, or simply make a comment on the Google doc with the info to add

For reference on how this works, see the 2015 ShmooCon list

Link to the google doc:

Read More

Thursday, September 10, 2015

Tres Lessons from Pied Piper Delete Key Hack

By With
The teflon crew at Pied Piper suffered quite a bit during Season 2 of SILICON VALLEY. But there was no greater indignity than being brought to their knees by a tequila bottle.

Since episode eight “White Hat/Black Hat” aired, many skeptical viewers have asked: how could something like this happen?

Could a mindless error of pressing a delete key really cause a venerable company like Intersite to lose over nine thousand hours of content (including an irreplaceable archive of vintage yiffing videos)?

The short answer: yes.

When the producers of SILICON VALLEY reached out to me during the writing of the episode to help design the sequence, I knew it would be tough to make the technical intricacies track for the joke. But if the team had figured out optimal tip-to-tip of efficiency with Stanford PhDs, I was up for the challenge.

The delete key hack is a perfect storm of bad system hygiene. The dozens of small errors that led to it are more common than most systems administrators care to admit.

There’s a lesson here. Away from the big headlines about hacks at Sony Pictures and Target, companies every day have their systems broken by stupid errors. Most as avoidable as not putting a tequila bottle on a laptop (or letting Russ Hanneman inside your home in the first place).

Below is the the post-mortem on how the hack went down and tres lessons we can learn from it.

The Bake-Off

Intersite set up the bake-off between Endframe and Pied Piper by providing access to an FTP server with the target files. Each company then downloads the individual files, encodes, compresses and roundtrips the file back to the Intersite server.

To speed up the process of the compression, the companies sequentially encode each file to save hard drive space and time waiting for them all to copy down, then they perform the operation.

This is where all the problems originate: to deliver the compressed file, Pied Piper was given full permission to Intersite’s FTP server (because of course it’s easier to just give all permissions than manage every folder’s permissions).

For those interested, the final Pied Piper solution for Intersite would look something like this:

The Hack

When Russ sets down the Tres Comas tequila bottle on Richard’s laptop he unwittingly initiates a massive delete sequence on Intersite’s server. Here are the steps:

  1. Richard navigates to bake-off directory or with the extended permissions he got into a parent folder with original content.
  2. Gilfoyle turns off the delete verification prompts in the custom software they used for the file transfer and conversion. Richard meanwhile has enabled CRC checking on the internet system, a protection measure for penetration into Pied Piper that backfires.
  3. Russ Hanneman arrives with the Tres Comas Tequila and mistakenly sets the bottle down on the keyboard initiating a delete command. Chaos ensues.
  4. As the delete sequence launches the large file size of video spins the disks at 100% and locks the system.
  5. Hands-on access with the bottle with the persistent delete requests plus the CRC checking creates fork bomb-like effects where the Pied Piper team cannot get back into the system to stop the delete sequence. Intersite is compromised and thousands of hours of video are deleted.

Tres Issues

A myriad of problems contributed to the delete key hack. Using the OWASP framework here are the top tres issues:

A7 - Missing Function Level Access Control “PITA Administration”
Intersite’s FTP server is set up to allow the bake-off users full permissions to the digital masters being used in the bake-off.

But why were they unable to kill the transfer? There are a bunch of reasons this could happen -- the SAN of which they were FTP’ed into was doing massive amounts of data deletion which can be HDD intensive (try deleting over 9000 files and watch your computer crawl).

But they would still be able to kill it on the Pied Piper end?! Not if the transfer agent was queuing up deletes as fast as it could, pegging out the server on the Pied Piper end as well. Remember, everything they had in their garage data center was going into making the conversions go as fast as possible, the transfer back was a lower priority.

A4 - Insecure Direct Object Reference “speed is everything”
By not locking out his screen and letting Russ Hanneman near his unsecured session where he was monitoring the transfer from, Richard allowed direct access to the “delete” key object.

But why didn’t it prompt for approving the delete? Basically when you’re in a bake-off like this, you do absolutely everything to remove any possible obstacles, like ANY prompts or approvals that you might not be around to hit “OK” on.

A6 - Sensitive Data Exposure “We must run forward simply to stay in place”
Intersite did not do a proper backup of their files due to cost and size constraints on their current system. In Episode 7 “Adult Content,” Molly Kendall, Intersite’s CEO, talked about how the porn industry was barely making the bills due to “free” internet porn influx. Intersite was doing its best to stay afloat in its industry and, as such, cut corners not only in the lack of proper admin for their FTP server, but also in storage costs. A mistake they will probably not make again soon.

Tres Lessons

Don’t be an idiot with permissions:
The easiest way in is through the front door. Ensure that everyone is on a need-to-know basis with data. Standard protections like 2-factor authentication and whitelisting IP addresses mean nothing if the wrong people access sensitive information.

Back up your data:
It’s easy to take for granted but reliable storage is still expensive. Most small businesses don’t backup data on a daily basis. Even fewer do so with any form of redundancy or integrity checks.

Don’t work with assholes:
Insider attacks are the hardest to detect and protect against. Surveys estimate 59% go unnoticed until it is too late. The first line of defense is common sense, only hire people you trust — and definitely not anyone who put radio on the Internet.

Read More
Home About-us Privacy Policy Contact-us Services
Design By Templateclue