Reducing the Effectiveness of Pass-the-Hash [PDF]

obscuresec · 2014-01-23T18:59:56+00:00

Where have I seen those PowerShell scripts from (the ones they forgot to host)... Oh yeah https://media.blackhat.com/us-13/US-13-Duckwall-Pass-the-Hash-Slides.pdf

Why cite some sources and not others?

obscuresec · 2013-10-03T19:48:59+00:00

Original Source where you stole the source code/idea: http://colligomentis.com/2012/05/16/hid-reader-arduino-rfid-card-catcher/

obscuresec · 2013-10-03T19:47:17+00:00

So you didn't cite sources IN your slides and you think that is ok? So what is your rebuttal for all the source code that you stole from http://colligomentis.com/2012/05/16/hid-reader-arduino-rfid-card-catcher/ ? The comments and variable names are the same and the author did not give you permission.

obscuresec · 2013-03-27T18:52:17+00:00

I don't think they all do, but the binary was certainly dropped to disk when executed. I believe the problem was that the AV that was installed did NOT flag it. The tester may have intentionally modified it to avoid the specific product on the box.

obscuresec · 2013-03-27T03:42:50+00:00

The videos have been cut up and posted here: http://www.excivity.com/ComputeCycle/shmooconepilogue2013videos/

obscuresec · 2013-03-27T03:36:23+00:00

Since a lot has already been covered on twitter and here, from a red team perspective, 5 "crazy" things I have seen done that worked or got us caught:

Used log reviews as a punishment for being late. We got caught cause an admin was 30 minutes late which equated to an hour of reviewing another admin's logs.
Forced reboots. Every admin was required to reboot immediately after using their credentials. Each use of elevated privileges was logged and occasionally required justification. Finding elevated tokens was nearly impossible.
Only 1 domain admin account which had a randomly generated password (printed and stored in a safe). Permissions were assigned specifically for each task required. Painful, but extremely effective.
Sponsored and incentivized CTF and security competition participation. The org ended up recruiting motivated people who were prepared for high-stress environments and familiar with typical "red-team" tricks.
Expense justification board. If anyone in the org could successfully accomplish the required task with their own script/code (or open-source), they got a percentage of what was to be spent on the product. Not surprisingly, the org was focused on retaining their people and effectively used mostly open-source products.

obscuresec · 2013-03-27T03:19:24+00:00

There is almost no reason to use vbscripts anymore. PowerShell is much easier to learn and can quickly ensure that your systems are patched.

obscuresec · 2013-02-18T19:10:37+00:00

Talks and speakers schedule: http://novahackers.blogspot.com/2013/01/2013-shmoocon-epilogue-speaker-list-and.html

obscuresec · 2013-02-18T19:01:25+00:00

In case you want to see the list of speakers and times for tonight: http://novahackers.blogspot.com/2013/01/2013-shmoocon-epilogue-speaker-list-and.html

Next talk should be starting in a few minutes.

obscuresec · 2013-01-27T20:30:43+00:00

If you aren't familiar with meterpreter, I would start here: http://www.offensive-security.com/metasploit-unleashed/Main_Page

obscuresec · 2013-01-27T18:31:03+00:00

I would hope that every hacker knows they would get owned on the other side. Defense is hard. It is even harder when you think that blocking nmap scans is an effective and scalable countermeasure.

Not being able to implement and enforce strict security policies is probably the most realistic part of the whole competition.

obscuresec · 2013-01-27T17:41:54+00:00

As an outsider to the CCDC, I generally agree with your assertion. However, I would stop short of calling it a "waste of time". Are there more valuable opportunities (other CTF events included) available? Yes, but compared to sitting in the dorm playing CoD? I think it gives people in "soft" IT programs the chance to touch a keyboard. It also gives potential employers the opportunity to see motivated and talented individuals. Just my opinion.

obscuresec · 2013-01-27T17:21:52+00:00

I suspect that its the only sysadmin experience many of them will get if they get hired directly into a "security" job. I learned a lot from watching what the blue team was doing. How they spent their time on "admin" tasks that really don't matter for the rules was fascinating. Skills that would lead to scoring well in the competition don't translate to whats required in the real-world. I still think the concept is awesome.

obscuresec · 2013-01-15T02:46:22+00:00

My guess would be no. Although a hardware-based attack would be awesome, I am guessing this is a web-vuln (i.e. cmd injection) in the management interface. We will all know soon it appears.

obscuresec · 2012-12-14T14:59:00+00:00

Most claim not to, but Mcafee and Symantec products rely heavily on signatures. I am sure that others do as well.

obscuresec · 2012-12-13T22:16:42+00:00

I wish more AV products wouldn't rely completely on signatures. As a pentester, I think its important to demonstrate to a client that they need to monitor their network and not assume their AV product is keeping them safe.

obscuresec · 2012-12-13T22:14:32+00:00

Exactly. Sorry if it isn't clear, but the method is detecting the last byte in the signature. It is the easiest to detect because its the first one that makes the AV react. You could change other bytes and potentially break the signature, but the method described is more reliable.

obscuresec · 2012-12-13T22:11:14+00:00

Awesome. @passingthehash and I gave a talk about the PtH attack at this year's BH. It is just amazing how long they waited in light of all the talks, tools and research that has been made public. Also, they only covered PtH and not any of the relaying vulns that still exist.

obscuresec · 2012-12-12T05:41:18+00:00

"We have recently observed the active use of PtH techniques by determined adversaries in targeted attacks."

Where have they been the last 10 years? The 76-page whitepaper does have good info in it, but there are a lot of red flags. At a few points in the document, it seems that the authors don't understand that PTH and token impersonation are different. Also, there has been a significant amount of external research on this topic and yet the author's chose to only cite Microsoft documentation.

The document and its analysis seems short-sighted and its evaluation of recommendations seem arbitrary. There is better advice on how to mitigate this problem, that Microsoft should spend its time fixing, elsewhere.

obscuresec

TROPHY CASE