These are just (essentially) my raw notes dumped from the talks I attended at BSides Seattle (2015-ish). Unfortunate I developed a migraine so I only caught the morning talks.

Active Directory

• Use scripts to dump AD
• Use scripts to sync with 3rd party providers
• Lots of story, not much technical depth

Red Team

• Presenter: Sean Malone, FusionX

• Types of Security Assessment
  • Vulnerability Assessment
    • Find vulnerability
    • Limited Scope
    • Broad & Shallow
    • Cooperates with SecOps
  • Pentesting
    • Achieve Technical Compromise/Domain Admin
    • Moderate Depth
    • Techniques include Network, Application Assessment
  • Red Team
    • Narrow Scope
    • Whole Enterprise is In Scope
    • Techniques include Social, Physical, Technical
    • RT Objectives
      • Simulate Sophisticated Adversary
      • Achieve “Nightmare Scenario” without detection
    • Client Objectives
      • Understand resiliency
      • Risk reduction, not just vulnerability count
• Effective Red Teams
  • Hyper-realism (go all the way)
  • Do No Harm
  • Zero-Knowledge
    • Offensive team does not use any inside knowledge
  • Zero-Notice
    • No notice to defensive team
• Developing Steps
  • Adversary Scenario
    • Who?
      • Nation-state?
      • Commercial Competitor?
      • Hacktivist?
    • Why?
      • Steal information?
      • Destabilize?
    • Impact
    • Objective
    • Starting Point
  • Campaign Plan
    • Be Creative
      • Wide Variety of Approaches
      • Webapps
      • USB Drives
      • Social Networking
      • Legal limits: can’t bribe someone, can’t blackmail someone, etc.
    • Be Adaptive
      • Can’t know how everything will go
      • May have several different approaches planned out, use as needed
    • Be Resilient
      • Even if detected, engagement is not over
      • Keep different techniques/footholds isolated
    • Even if technique is known to work (phishing, link clicking, social engineering), there is value in doing it
      • Is it detected?
      • Can mitigations come into place in time to prevent lateral movement/escalation?
  • Scope
    • Think Globally, Strike Precisely
    • Whole Enterprise in Scope
    • Stay Focused
      • Only move towards objective
      • May not be linear path, but still move to goal
      • Exploiting unnecessarily increases risk of detection
    • Right to Audit clause in Vendor Agreements Critical
    • Client should not limit scope
      • Confirmation bias
      • If concerned about availability, pretty big sign that system is already too weak
      • Forcing red team into small box does not simulate adversaries
  • Rules of Engagement
    • Should not need to get pre-approval for every exploit/phishing email/etc.
    • RoE should allow autonomy to exploit, move laterally, and escalate
    • Client should still be informed, have ability to push “big red button”, but red team should not wait for ACK (too slow)
    • Attacker should have 24x7 window (again, better simulates real-world adversary)
      • Vulnerability in timing is just another vulnerability
    • Predefined rules for sensitive data
      • Access is necessary to simulate adversary; avoid unrealistic limitation that impacts the accuracy of the assessment
      • Expectation should be that Red Team may see any data on any system (IP, passwords, HR data, whatever)
      • Rules for what can be used (i.e., personal credentials generally off-limits)
      • Rules for how to dispose of data at end of engagement
      • Rules for where data can be moved (i.e., shipping PII outside network?)
      • Retrieve minimum number of records to demonstrate impact
      • Redact in report
  • Communication & Escalation Plan
    • Need-to-Know Basis
      • Statement of Work vague, have separate authorization signed by CISO to avoid leaking even to procurement team
    • Keep Blue Team in the dark (adversaries don’t call ahead!)
      • Can’t accurately evaluate detection & response if they know
      • Point of Contact should have visibility into SOC
      • If SOC is overwhelmed by exercise (+ real intrusion?), suspend exercise
• Summary
  • Only executive has authority to approve something broad enough
  • Technical compromise doesn’t matter if you can’t show impact
  • Stay focused
  • Maintain OpSec
  • Keep objective in mind
  • Risk/Reward to get closer to objective
  • Agile, Adaptive, Opportunistic

A couple of coworkers who have never been to DEF CON, BSides Las Vegas or Black Hat (collectively, “Hacker Summer Camp”) asked me about planning their first trips, so I decided to collect my tips here. I’m going to be splitting my advice into two parts: this planning guide for travel/scheduling/registration information, and a Hacker Summer Camp survival guide for advice that’s more relevant while you’re at the conferences.

Manage Your Energy

There’s a lot to do, the hours tend to be long, and unless you’re used to both the environment (typically hot, this is Las Vegas in August!) and the crowds, it’s going to burn a lot more energy than you’re going to expect. Two years ago, I attended all 3 of the conferences, helped run a company suite, and taught classes at R00tz (formerly DEF CON Kids). This was a serious mistake on my part, and failure to manage my energy adequately. I ended up not getting as much out of any of the events as I should have, and when I returned, I ended up sick for several days due to the toll of these events on my body. It was more than a full week afterwards before I felt fully recovered.

If this is your first time, don’t try to do everything. Firstly, it’s just not possible, and secondly, you will destroy yourself trying to do so. Prioritize, and make yourself okay with the fact that some things you’ll just miss out on. For myself, the most important parts of the week are:

• Activities – I learn more by doing than by listening to some speaker try to tell you what he did in 45 minutes. I typically play in the BSides LV CTF and Capture the Packet at DEF CON. Others might find the DEF CON Shoot to their liking. (I’d probably like it too, but always end up busy on Thursday.)
• Villages – Villages are a set of topical/related presentations and activities that are presented by people who are very into the particular topic. I’ll usually visit the tamper-evident village, lockpicking village, wireless village, and whatever is new. If you’ve never tried picking a lock, it’s really interesting just to see how the process goes, and the guys in the lockpicking village can tell you anything you wanted to know about any lock.
• Networking – One of the most important aspects of DEF CON is networking, and it’s not just about lining up your next job. This industry is full of back-channel connections that help you get information, securely report a vulnerability, or help you find a solution to a problem. You’ll find out things that aren’t publicly known, learn who to talk to about esoteric technology, and generally meet some great people.
• Talks – Talks are good and are obviously a core part of all of the conferences, but to me, they take a back seat to the above categories. This isn’t because I don’t like the talks (I do!) but because the other categories require your in-person presence and participation. Unless you want to ask the presenter a question, the talk won’t be recorded, or you really want to know about it before the recording becomes available, being there in person adds very little to the value of a talk.
• Parties – Rumor has it that DEF CON, Black Hat, and BSides may also have parties. These rumors are completely unfounded. There is absolutely no partying, live music, alcohol consumption, or any other fun to be had in Las Vegas during these events.

Scheduling

Black Hat Briefings are Wednesday and Thursday, with trainings either Saturday-Sunday or Monday-Tuesday (or sometimes covering both for bigger trainings). BSides LV is Tuesday and Wednesday, with a pretty full schedule both days. DEF CON is Thursday-Sunday, but Thursday doesn’t really get started until the afternoon (and even then, the villages have not historically been open), and things start to wind down a little bit Sunday afternoon, so Friday and Saturday are the “core” for DEF CON.

1 Conference, 2 Conferences, 3 Conferences?

So which conferences do you want to go to? Well, that really depends on what you’re looking for. I strongly suggest not trying to do all 3: you’ll end up just half-doing all 3. (This is borne out by personal experience.) Here’s what I see as the tradeoffs:

Common Elements

All 3 conferences have excellent technical content, and many of the presentations will be at more than one conference. Many of the attendees will be at more than one as well, so you’ll be running in to the same people throughout the week.

DEF CON

DEF CON is, by far, the biggest of the 3 conferences – reportedly somewhere around 14,000 attendees. It has the most hands-on activities with the villages, and most of the parties (oh wait, what happens in Vegas stays in Vegas…). DEF CON is somewhere between casual and chaotic, and is, of course, the conference that started the whole week of Hacker Summer Camp 24 years ago. For me, DEF CON is the “can’t miss” part of the week, as it has the most learning opportunities, most social networking opportunities, and most of the people I look to catch up with will be at DEF CON. The Vendor area at DEF CON is not a trade show – it’s suppliers who will sell you tools, books, parts, lockpicks, t-shirts, and other things for the individual to use, rather than a “turnkey enterprise solution.”

Black Hat

Black Hat is the business side of the week. If you’re most comfortable in a shirt and khakis, then this might be the conference for you. If you need a large trade show-esque vendor area, they have it. The talks remain high-quality, but it’s definitely got the feeling of corporate-run, enterprise-focused, and very little “community.” It’s also worth noting that Black Hat is an order of magnitude more expensive than DEF CON, so that may influence your choices.

BSides Las Vegas

BSides LV started as the “B-Side” to Black Hat: an opportunity for smaller presenters, attendees without the budget for Black Hat, and more. It’s grown into a network of regional conferences, and has expanded to a number of tracks of talks in Las Vegas. Most interestingly, they have a track dedicated to first time speakers, so you can get to meet some up and coming presenters and support those new to the scene. BSides is the most calm and laid-back of the 3 conferences, and a very casual environment. BSides is also the cheapest ($25 last year, if I recall correctly) and held at a hotel with dirt-cheap room rates ($49/night or so), so is clearly a way for a hacker on a budget to enjoy hacker summer camp. (They also offer a shuttle between the BSides hotel and DEF CON, so you can enjoy their low room rate all week!)

Travel

I’m told driving to DEF CON can be a great deal of fun when done with the right people, but I haven’t managed to do so myself. I imagine doing it yourself isn’t much fun. Do keep in mind that you’ll be driving through the desert, so a reliable vehicle is a must, and bring water, just in case.

Las Vegas, as a center of tourist travel, has relatively convenient air travel options from pretty much anywhere. From the SF Bay Area, there’s several direct flights a day from any of the 3 local airports, and on several airlines, and it’s just over an hour gate-to-gate. Keep an eye on airfare early and look for deals – booking early can easily save more than $100 on airfare. When planning, particularly for your departure from Las Vegas, please keep in mind that DEF CON travelers on Sunday evening are numerous enough to cause significant delay at airport check-in and security, so allow extra time.

Hotel

There’s two schools of thought on hotel: stay at the conference hotel (for one of the conferences, if doing more than one), or stay away from the conference hotel. I personally prefer the DEF CON hotel (i.e., Bally’s or Paris for DEF CON 24), but I’ll review the pros/cons of each so you can make up your own mind:

Staying at the Conference Hotel

• (Pro) You can easily get back to your hotel room after evening “social activities”.
• (Pro) It’s easy to dump stuff in your room so you don’t have to carry everything around. (This can be somewhat mitigated if you have a friend staying there.)
• (Pro) It’s fun to meet random people from the con around the hotel.
• (Pro) Usually, DEF CON sets up “DEF CON TV” to the rooms in the DEF CON hotels, which will live stream the talks, so if there’s one you really want to see but the room is slammed, you can watch it from your room. (Or you can hang out with some new friends, drink a couple of beers, and watch talks from your room.)
• (Con) Everywhere at the hotel will be busy. Everywhere. Every bar, restaurant, and shop, will be slammed at all hours. Seriously.

Staying Elsewhere

• (Pro) You get a break by getting away from the conference. This can be a good option for introverts. (Though I personally find going to my room enough for that – I usually need to do so about once per day to mentally recharge.)
• (Pro) You can often find much better deals off site, especially if you start looking early. DEF CON even has room block that is close by, but not Paris/Bally’s, and is generally cheaper than those hotels.
• (Pro) Food options will be much less busy than at the conference hotel.
• (Con) You’ll need to get back and forth to the conference, which may negate some of the potential savings. (You may think you can walk, but temperatures during this week often exceed 100°F (38°C))

Other Things to Be Aware Of

• As of DEF CON 24, registration is $240, cash only at the door. Since DEF CON 20, pricing has fairly consistently been ($year * $10) – so $200 at DC 20, $220 at DC 22, $230 at DC 23, and this year will be $240 for DC 24. While historically, there have been crazy waits for badges, registration got much better with DEF CON 23.
• Currently, even numbered years get electronic badges, and odd numbered years get non-electronic badges. The electronic badges tend to run out, so you may want to make sure you get a badge on Thursday (they’re usually good through Thursday) if that’s important to you.
• International travelers: Las Vegas basically runs on tips. Nearly everyone expects to be tipped.
• Be an active participant. I’ve personally spent too much time not participating: not talking, not engaging, not doing. You won’t get the most out of this week by being a wallflower.

Resources

There are a lot of resources for finding out more about what’s going on. Obviously, the conference websites are your first stop, but as DEF CON is a large community event, there’s also more opportunities out there:

• /r/defcon
• @defcon
• DEF CON Forums

Conclusion

I hope this proves helpful to those new to DEF CON. Get out there, meet people, and have fun. If you’re a seasoned veteran and see some suggestions I’ve missed, please email me or find me on twitter: @matir with your suggestion and I’ll add it.

Thanks to the @dc404 group for some of the additions and suggestions!

This isn’t the first time I’ve changed blogging platforms, and it probably won’t be the last. I got tired of having to do maintenance on a blogging platform, so I decided to look for something lightweight. Enter Jekyll.

Jekyll is basically a static website compiler – it takes templates and content and produces static HTML output. No databases, no runtimes, no attack surface (beyond a static webserver). Given that I don’t mind writing in Markdown (in fact, I was using a Markdown plugin for Mezzanine), it seemed like a perfect fit. I wrote a quick script to get content out of Mezzanine/Django and export as HTML/Markdown, then spent some time tweaking the settings and theme (based on Hyde).

I’m going to be setting a goal to blog at least once a week, so watch this space for updates. And if you notice something odd going on (I know there are some issues with old posts and code blocks) please email me or ping me on Twitter.

It’s been a little bit since I last updated, and it’s been a busy time. I did want to take a quick moment to update and note that I accomplished something I’m pretty proud of. As of Christmas Eve, I’m now an Offensive Security Certified Professional.

Even though I’ve been working in security for more than two years, the lab and exam were still a challenge. Given that I mostly deal with web security at work, it was a great change to have a lab environment of more than 50 machines to attack. Perhaps most significantly, it gave me an opportunity to fight back a little bit of the impostor syndrome I’m perpetually afflicted with.

Up next: Offensive Security Certified Expert and Cracking the Perimeter.

The text was just:

I think my SATA controller is dying.

HINT: git fsck -v

And included a tarball containing a git repository. If you ran the suggested git fsck -v, you’d discover that 3 commits were corrupt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
:::text
Checking HEAD link
Checking object directory
Checking directory ./objects/2b
Checking directory ./objects/2e
Checking directory ./objects/35
Checking directory ./objects/4a
Checking directory ./objects/4c
Checking directory ./objects/7c
Checking directory ./objects/a1
Checking directory ./objects/cb
Checking directory ./objects/d5
Checking directory ./objects/d9
Checking directory ./objects/e5
Checking directory ./objects/ef
Checking directory ./objects/f8
Checking tree 2bd4c81f7261a60ecded9bae3027a46b9746fa4f
Checking commit 2e5d553f41522fc9036bacce1398c87c2483c2d5
error: sha1 mismatch 354ebf392533dce06174f9c8c093036c138935f3
error: 354ebf392533dce06174f9c8c093036c138935f3: object corrupt or missing
Checking commit 4a2f335e042db12cc32a684827c5c8f7c97fe60b
Checking tree 4c0555b27c05dbdf044598a0601e5c8e28319f67
Checking commit 7c9ba8a38ffe5ce6912c69e7171befc64da12d4c
Checking tree a1607d81984206648265fbd23a4af5e13b289f83
Checking tree cb6c9498d7f33305f32522f862bce592ca4becd5
Checking commit d57aaf773b1a8c8e79b6e515d3f92fc5cb332860
error: sha1 mismatch d961f81a588fcfd5e57bbea7e17ddae8a5e61333
error: d961f81a588fcfd5e57bbea7e17ddae8a5e61333: object corrupt or missing
Checking blob e5e5f63b462ec6012bc69dfa076fa7d92510f22f
Checking blob efda2f556de36b9e9e1d62417c5f282d8961e2f8
error: sha1 mismatch f8d0839dd728cb9a723e32058dcc386070d5e3b5
error: f8d0839dd728cb9a723e32058dcc386070d5e3b5: object corrupt or missing
Checking connectivity (32 objects)
Checking a1607d81984206648265fbd23a4af5e13b289f83
Checking e5e5f63b462ec6012bc69dfa076fa7d92510f22f
Checking 4a2f335e042db12cc32a684827c5c8f7c97fe60b
Checking cb6c9498d7f33305f32522f862bce592ca4becd5
Checking 4c0555b27c05dbdf044598a0601e5c8e28319f67
Checking 2bd4c81f7261a60ecded9bae3027a46b9746fa4f
Checking 2e5d553f41522fc9036bacce1398c87c2483c2d5
Checking efda2f556de36b9e9e1d62417c5f282d8961e2f8
Checking 354ebf392533dce06174f9c8c093036c138935f3
Checking d57aaf773b1a8c8e79b6e515d3f92fc5cb332860
Checking f8d0839dd728cb9a723e32058dcc386070d5e3b5
Checking d961f81a588fcfd5e57bbea7e17ddae8a5e61333
Checking 7c9ba8a38ffe5ce6912c69e7171befc64da12d4c
missing blob 354ebf392533dce06174f9c8c093036c138935f3
missing blob f8d0839dd728cb9a723e32058dcc386070d5e3b5
missing blob d961f81a588fcfd5e57bbea7e17ddae8a5e61333

Well, crap. How do we fix these? Well, I guess the good news is that the git blob format is fairly well documented. The SHA-1 of a blob is computed by taking the string blob , appending the length of the blob as an ASCII-encoded decimal value, a null character, and then the blob contents itself: blob <blob_length>\0<blob_data>. The final blob value as written in the objects directory of the git repository is the zlib-compressed version of this string. This leads us to these useful functions for reading, writing, and hashing git blobs in python:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!python
import hashlib
import zlib

def git_sha1(blobdata):
    return hashlib.sha1(("blob %d" % len(blobdata)) + "\0" +
            blobdata).hexdigest()


def read_blob(filename):
    raw = open(filename).read()
    raw = zlib.decompress(raw)
    metadata, data = raw.split('\0', 1)
    _, size = metadata.split(' ')
    size = int(size)
    if len(data) != size:
        sys.stderr.write('Metadata shows %d bytes, data is %d.\n' % size,
                len(data))
        sys.stderr.flush()
    return data


def write_blob(filename, blob):
    with open(filename, 'w') as fp:
        fp.write(zlib.compress(('blob %d\0' % len(blob)) + blob))
        fp.flush()

We’ll use these to fix each of the commits in turn, but to do that, we need to figure out the busted commits and how to fix them. Using the combination of git log and git ls-tree, we can figure out the blobs for each commit and find that the order of the blobs is:

1
2
3
4
5
git log --oneline | tac | awk '{print $1}' | while read commit ; do git ls-tree $commit ; done | grep sharp.cpp
100644 blob efda2f556de36b9e9e1d62417c5f282d8961e2f8	sharp.cpp
100644 blob 354ebf392533dce06174f9c8c093036c138935f3	sharp.cpp
100644 blob d961f81a588fcfd5e57bbea7e17ddae8a5e61333	sharp.cpp
100644 blob f8d0839dd728cb9a723e32058dcc386070d5e3b5	sharp.cpp

So, the 3 broken blobs are, in order: 354ebf3, d961f81, and f8d0839. We can use git cat-file blob <id> to see the contents of each and look for obvious corruption. Doing this to the first file, we see a valid C++ file, with no syntactic corruption.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!c++
#include <iostream>
#include <string>
#include <algorithm>

using namespace std;

int main(int argc, char **argv)
{
	(void)argc; (void)argv; //unused

	std::string part1;
	cout << "Part1: Enter flag:" << endl;
	cin >> part1;

	int64_t part2;
	cout << "Part2: Input 51337:" << endl;
	cin >> part2;

	std::string part3;
	cout << "Part3: Watch this: https://www.youtube.com/watch?v=PBwAxmrE194" << endl;
	cin >> part3;

	std::string part4;
	cout << "Part4: C.R.E.A.M. Get da _____: " << endl;
	cin >> part4;

	return 0;
}

Looking at line 16, we see the number 51337. Now, maybe I read too much into it, but it looks like 31337, which we all know is a slightly common number in CTFs. With no better reason, I decide to try replacing 51337 with 31337 and checking the blob hash. Works! Even though it’s overkill, I wrote a little script to do the fix:

1
2
3
4
5
6
#!python
def fix(filename):
    data = read_blob(filename)
    fixed = data.replace('51337', '31337')
    write_blob('blob.fixed', fixed)
    print git_sha1(fixed)

Running it, we get the hash 354ebf392533dce06174f9c8c093036c138935f3, and the file blob.fixed contains a new git blob, which we can place in the repository at .git/objects/35/4ebf392533dce06174f9c8c093036c138935f3. (At this point, I used git fsck -v to verify that we’re down to two corrupt blobs. Output omitted for brevity.)

Time to fix the next commit: d961f81. This includes the same 51337 -> 31337 fix, but there’s more corruption this time. This isn’t so trivial, but we get a clue from the commit for this blob:

There’s only two factors. Don’t let your calculator lie.

Looking at the blob, we see this section:

1
cout << "Part5: Input the two prime factors of the number 270031727027." << endl;

Turns out that 270031727027 has 4 factors, so I suspect this number has gone wrong. Let’s try mutating the bytes there to find one that corrects it. (I could try checking for two factors, but this is fast enough to not worry about it.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!python
def permute_number(n):
    for p in range(len(n)):
        for i in string.digits:
            val = n[:p] + i + n[p+1:]
            yield val


def fix(filename):
    data = read_blob(filename)
    rawlen = len(data)
    before, after = data.replace('51337','31337').split('270031727027')
    for permute in permute_number('270031727027'):
        data = before + permute + after
        assert rawlen == len(data)
        if git_sha1(data) == target:
            print 'Found number: %s' % permute
            write_blob('blob.fixed', data)            
            break

This only takes a second to tell us that the number should be 272031727027 instead. The SHA1 matches, and we copy it to .git/objects/d9/61f81a588fcfd5e57bbea7e17ddae8a5e61333. git fsck -v again to check that git sees it correctly, and we’re off to the final blob. It turns out this one is very easy to fix by inspection, once we see this segment:

1
2
3
4
5
#!c++
std::string flag = calculate_flag(part1, part2, part4, factor1, factor2);
cout << "flag{";
cout << &lag;
cout << "}" << endl;

There is no variable named lag to take a reference of. Since the length is right, maybe we should try just changing that to flag. Incorporating our previous fixes, we get this fix script:

1
2
3
4
5
6
7
8
#!python
def fix(filename):
    data = read_blob(filename)
    fixed = data.replace('51337', '31337')
    fixed = fixed.replace('270031727027', '272031727027')
    fixed = fixed.replace('&lag', 'flag')
    print git_sha1(fixed)
    write_blob('blob.fixed', fixed)

Again, we copy to the objects directory. Now that git fsck -v reports a good repository, we reset to HEAD to get the right version of the C++ source (though we could have just taken the fixed variable from our script above, to be honest) and build it, then run it:

1
2
3
4
5
6
7
8
9
10
11
12
13
:::text
Part1: Enter flag:
flag
Part2: Input 31337:
31337
Part3: Watch this: https://www.youtube.com/watch?v=PBwAxmrE194
foo
Part4: C.R.E.A.M. Get da _____: 
money
Part5: Input the two prime factors of the number 272031727027.
31357
8675311
flag{3b532e0a187006879d262141e16fa5f05f2e6752}

Bam! 400 points in the bank.