← All talks

Metlstorm's Empiricism Emporium: Unpleasant Truths Our Speciality

BSides Wellington · 20171:12:471.3K viewsPublished 2018-02Watch on YouTube ↗
Speakers
Tags
About this talk
Adam Boileau draws on two decades of offensive security experience to dissect how organizations actually get compromised. He walks through the attacker's mindset—from initial access through domain admin persistence—and examines systemic failures in Active Directory, cloud integration, and supply chain trust. The talk challenges the infosec industry's defensive posture in New Zealand and globally, arguing that empiricism and lateral thinking separate operational hackers from researchers.
Show original YouTube description
The saying goes, "you can lead a horse to water, but you can't make it drink." After twenty years in infosec, I'm about ready to grab that nag's mane and shove its stupid wizened up old prune-face in the trough. We all know it ain't gonna rehydrate itself, but at least I'll feel better while it coughs and splutters, and maybe, just maybe, it'll think about what it's done while it tries to choke down its nosebag full of dry cloud oats after. In this talk, Metl will talk about how he feels about the state of Infosec in New Zealand (spoiler: cranky), how to hack everyone and everything (spolier: easily) and what we're going to do about it (spoiler: cry?).
Show transcript [en]

Wow. Besides, hello, hi to you. My name, as you're probably aware, is Metal Storm. And it is a pleasure to be here. It's been a long time since I've talked at a Hackacon. In fact, actually, this is the first Hackacon in New Zealand I've ever been to because every other Hackacon in New Zealand, well, This is KiwiCon1. I'm speaking about, it looks like spanning tree protocol, which fortunately that's not a thing anymore because, lord, that was terrible. Here I am being supervised by pipes to make sure I didn't do anything wrong. The fact that he's wearing our KiwiC t-shirt, I guess, implies that we hadn't quite grown up in the code of conduct sense at that point, but oh well. We got a

little bit better, I hope. But yes, every other time that there's been a hackacon in New Zealand, and I like the I would like to think that I have something worthwhile to share, but every other time it's just been, you know, organizing a con, as you found out, is quite a lot of work, you know, and all of the important things that you have to do as a con organizer, right, they take a lot of time and a lot of effort, and it's very complicated, you know, there's a lot involved with making hexagons, right, that's serious business. And yeah, so I've been a little bit busy, you know, with all of the, you know, serious,

organizing stuff so I haven't really had time to do a whole bunch of content. You know, I've got to find 10,000 blue M&Ms so that Faley will go on stage. And so yeah, I've never actually been to a hackathon. This is what hackacons in New Zealand look like to me. This is backstage during Jess Fraze last year. And this is how I spend my hackathon, standing at the side of the stage with Squirrel in the kind of space nest that he makes backstage. He's got one here as well, but it's not quite as big. But this is what a hacker con looks like to me. And so, you know, I was a little trepidatious, I guess, about submitting to somebody else's con, like somebody else's stage, like getting

up here, and honestly, it feels kind of weird. Like we had a lot of talks about imposter syndrome. The idea of getting up at somebody else's hacker con, like without the defense of being able to say, oh, I'd be busy running a con, like, you know, I didn't have time to prepare anything. Like maybe I don't have anything to say. It's quite intimidating in a way. And then, of course, like I... I didn't want to go on stage without... Fire, fire, fire, fire. I'm a fire. But then it turns out that they foxed me. I said, no, look, I can't do it. You don't have pyro. You're not allowed to have pyro in here because

the shed will burn down. But they foxed me on that one as well. Bogan suggested that he get a can of Lynx and a cigarette lighter. Such a feral, that guy. And so, yeah, here I am. And...

I wanted to talk to you today about empiricism. And I guess, having been doing this for a while, I have some opinions. Actually, you're probably not surprised. And I thought I would share them with you. And in particular, what I wanted to talk about today is the relationship between how we defend and how we attack. And I wanted to talk about how people get hacked. based on my experiences of doing it. I've been in this industry pushing 20 years, the beard's starting to get a little bit gray. I've been doing this for a long time, something like, I guess, basically 20 years, and of that, the last dozen, actually full-time breaking into people's networks for a living, and I'm very privileged to have

been able to do so, and be able to do the really fun bits of hacking and not go to jail like Plus of course you make reasonable cash which is good, it's intellectually rewarding which is nice. And I think the thing that I've really enjoyed in the last couple of years is as Insomnia has grown, we've hired, between Brett and Pipes and myself, we're at the helm of something like 25 hackers, all of whom are actually better hackers than I am, or if it was, which is absolutely great. all the people we've hired and some of them have had very little experience. We've hired for aptitude rather than experience and we've hopefully grown them into

some really good hackers. And that's been a really fun experience. And so yeah, I thought after this many years of doing it, hopefully I've got something insightful, I'm not 100% sure because, you know, gay imposters. I had the conversation with Shari walking into work the other day. I'm like, I've been writing this talk, I've written the first half four times now. I don't think I've got anything And it turns out, after all these talks about imposter syndrome, it is actually a thing that happens. You know, I'm nervous getting up on this stage. It's a tiny little stage, pocket size. But I'm still nervous getting up here, right? And so...

So yeah, I wanted to talk about how people get hacked. And I guess by people, I mean it in the modern kind of dystopian cyberpunk sense of corporations, of organisations, of agencies and entire ecosystems, to a sense. As we've seen several talks over the last couple of days, these are fundamentally about people. These are organizations built by people. They're broken into by people. And it's people who get on, people who roll incident response, people who ask, well, why is the power off?

those guys. But this is not a comedy talk. The talks that I have done at KiwiCon, I did technical talks, one, two, three, four. I did the Stone talk, I think maybe five or six. But I haven't done a technical talk in a long damn time. I've only done comedy ones. And this one, it's not a comedy talk. So we're going to talk about how people get hacked. And I guess the first question is, well, why, right? Well, the reason I wanted to talk about this is because the absolute majority, unfortunately, of people who make decisions about risk, you know, about governments and about policy and about defense and about technology purchases have, by and large, never actually hacked a thing.

And I think that influences how we defend. And not only have they never hacked a thing, they've probably never hacked several things or an entire system of things or an entire organization of things or an entire supply chain of things. And it's easy to frame this as Orin articulated so beautifully in the language of contempt, right? Which is the traditional way that we have done it as hackers, right? We've always said, oh, well, the man doesn't understand this shit like only we do because we're badass hackers. And that's not what I wanted to do. What I wanted to do here today, right, is to not frame it in that way, right? as empiricism, which is why this talk is called Empiricism Emporium. I wanted to talk about

my experiences of doing this, what I think I have learned from this, and what I really think that hopefully we can take away from that and from the fact that I've done this for quite a long time. And I was actually really pleased. Pipes' talk, we hadn't actually coordinated any of our material, and I ran through mine at the office the other day, and it turns out actually our talks line up really well. So hopefully that implies that there might be something to what we're saying. But really, yeah, I wanted to make this about some actual data about actually how things actually get hacked and go from there. Now, in this audience, given that this is a security enthusiast kind of conference, I imagine a lot

of you probably have actually hacked a thing, right? A web app or a bit of software. You bought a gadget. You pulled it apart to figure out how it worked. You've voided the warranty and maybe fixed a few things. And I think that we, this audience, such that I can see here, which is not at all, are probably slightly ahead of average in terms of our understanding of how things get hacked. And if I can have a little bit of crowd wash, please. Can you put up your hand if you have hacked a thing in this audience? Yeah, a few of you have hacked a thing. That's good. So keep your hands up. Don't put

them down here. It's good for depression, I heard earlier. So keep your hand up if from the thing that you hacked you pivoted through and hacked another thing. Okay, that's good, that's good. From there, keep your hand up if you then went and got domain admin or hacked some other centralized auth system, the Kerberos domain controller, the LDAP, whatever else. So if you pivoted on with domain control, that's really good. Okay, keep it up if you then moved onwards to some business target, obtained your action on objectives, as the Lockheed Martin Cyber Kill Chain would say. All right, that's cool. That's good. That's a few people still. How many of you have then gone onwards towards, I don't know, the

PCI card data zone or the SCADA HMI or the PKI that signs all the software? Okay, there's still a few. Keep your hand up if you've then taken what you've got so far and used that to move up and down the supply chain, pop the next organization, own them, kept going. Right, okay. So, policeman in the audience. There you go, job done. Right, top stuff. I'll take the... you know, take the money and go. So yeah, it was... That was Kate, if any policeman would like, no, she's the one who want you. So yes. But my point is, I think that there is a small group of people who actually do what we would consider weaponised hacking for a living. Obviously, some of them

are criminals, and they're not putting up their hands, presumably, allegedly not criminals. But this is a small group of people. There's probably 50 of us maybe in New Zealand that do this in the private sector. There's probably another 50 in the public sector, although we are the only of the five eyes that don't have a declared offensive capability, so maybe there aren't 50 people doing it, but, you know, it doesn't seem very likely. But, yeah, this is a small group of people, and it's a small group of expertise, and by and large, we don't get to talk about it much because of all of the NDAs. If you spend all day ruining other people's stuff and exposing their dirty laundry, you don't get to talk about it. And

obviously, I'm not going to talk about specifics for that very reason. Like, I like my job. I'd rather not go to jail. So we're not going to talk about specifics, but we'll talk about a few of the things that does define how we do hack things. But the group of people who make decisions about defense tend to not be those 50 of us that are doing offense. And so we're going to talk about how we defend. And I guess it's It's not unreasonable that the people, like we don't expect, as Serena said, we don't expect our users to have to understand this stuff, but perhaps it is reasonable to expect the people who are making policy and governance choices or technology

purchase choices or deciding how often you have to change your God damn password choices might be expected to, if not have done it themselves, to know that they haven't and obtain good data on which to base their decisions. And that's the empiricism that we're gonna talk about. So let's talk about how we defend. Now, I preface this by saying that there are some good defense options. Obviously, I'm here to talk about the ones that aren't good, because those are the ones we break into, but there are some good things, right? Darren from Google is in the room. Google Beyond Corp Initiative has taken years of hard work, and they are going in the right direction, right? There are some good options for OAuth, like U2F tokens, YubiKeys,

really do do a good job of what they have set out to do, right? There are some good toolkits in our defense. But by and large, We don't do it very well. And there's a couple of, I mean, I think there's a couple of areas where as a general, you know, consumers of technology, we are doing some things that are security relevant. For example, applying updates. Most people, I think, these days, if their system, you know, their OS on their laptop or their phone or whatever prompts them to update their stuff, They probably understand that that is actually probably a useful thing, except where the updates break stuff. Obviously, people don't like that. But in

general, most people understand that there is some vague reason why they're being hassled to update Java by the little pop-up, right? They don't do it, of course, but that's not the point, right? We at least have accepted that it's probably a good thing, unless... you go to the phone store and buy an Android phone that costs less than $1,000, in that case you're screwed, you don't get updates, and you should take your phone back to the carrier store and say, Consumer Guarantees Act, give me a goddamn phone that is actually supportable, and then maybe the carriers would actually go apply pressure to Samsung.

And we wouldn't be living in the goddamn Android shit show that we have. But anyway, but by and large, People who don't know how to hack make up how we defend. And I guess at best, they cause us to defend in the way that we hacked things 20 years ago. And at worst, we defend in the way that we think people hacked things 20 years ago. And I guess the best examples of that are going to be firewalls and antivirus. But this is not how we hack. This is not the 80s. Although that is a banging hairdo. I'd have a sweet mullet, right, if I did the chop off the top. Anyway. It's based on

what people think hackers do. And 20 years ago, I read this book, Firewalls and Internet Security by Cheswick and Bellowen. It is a classic. It explains why packet filters are good on the IPv4 internet. The IPv6 internet was still a dream at that point. I read this book. And then I turned around and went, you know what? Maybe we should put one of these newfangled packet filters instead of like an application layer gateway, which is all we did before then. Maybe we should put one of these fancy packet filters in between the iHug help desk and the internet. So I worked at iHug, I was a security guy at iHug at the time. If you

ever did anything bad at iHug in about the year 2000 and someone emailed abuse at iHug, that was my problem. I was the one who turned off your mom's internet, sorry. I decided, well, actually, you know what? Maybe it would be quite cool to put a packet filter in between the help desk and the internet. Because it turns out that the call center at the time had windows, I guess it would have been 95 boxes, with public V4s straight on the internet. And they'd wind pop up each other. And it was a great time. And we decided we were going to put them on RFC 1918 address space, NAT them, which, wow, that was quite

a big deal back then. I think we were talking like static route NAT. It's a 2-0 kernel with IP on a desktop box that we shelf mounted on the rack. So it was pretty ghetto back then. And the reason I did that is because someone shelled a Red Hat 6.2 box on the iHeartGlan using StatDX by Ronin, which was a sweet exploit of its time against the RPC StatD service. I thought actually the angsty 90s, what was her name, Jan Arden, her angsty 90s hit, what was it called, Intensive. was actually quite poignant given it's the year 2017. No one thought we'd be seeing source code from a C.C script, as we called them back in the day, up here on screen

in 2017, but that is actually how hackers hacked things back then. And back then a firewall control was actually a great idea. It stopped our Red Hat 6.2 boxes getting owned by script kits. So that was cool. But this, unfortunately, is how we defend today. Based on what we think, well, actually it's not what we think hackers do, it's what we think Qualys says. And Qualys says, oh my god, The humanity of the SSL, oh god. This is one box at a financial institute. One box, look how many SSL, and this is not even all of these, how many there were? And the bits that I've greyed out in the middle are not the bits

that got the box owned. The bit that got the box owned was the remote pre-auth arbitrary code exec as root against the service on the box that Qualys didn't bother checking for because Whoops, but, oh my God, the SSL certificates, oh God, oh God, look at them all. And the thing is, it worries about all this, and then we go and fix all our SSL certificates on the perimeter where it doesn't matter because no one's actually banned in the middle of anything on the internet other than the NSA who can already do it despite the certificates. And then we don't do it on the LAN where people actually can get in the middle, right, with some ARP or some V6 or DNS or whatever else they're doing. And

we don't do it there. We let everything be self-signed because YOLO, right? It's the LAN. It's totally secure. So we actually defend based on what Qualys thinks. And that's just a pure numbers game. Qualys has more TLS findings that it can enumerate remotely without any complicated auth or anything else. And that's how you end up with this. And we also defend based on what we see a hacker doing in our environment.

I don't know if you've noticed, whenever anyone uses hackers' GIFs, they never use Joey. They're always with the zero cool, always with the acid bin. No love for Joey, man. No love for Joey. Or Crusher, as we call him. What was his nick?

But the thing is, for most people, this is what hacking looks like. And if there's no DaVinci virus flipping your boat, you didn't get owned. And so we have no data on which to base. whether or not, or what hackers do in our environment because this is what people think. And I guess the best story to illustrate that is, I don't know if you remember 2010 Hell Pizza got owned. When I say owned, I mean someone used the, what was it, like SQL gate.jsp, which has a query parameter called query where you pass the SQL query. That's how the flash app that sold your pizza entered your order into the database. Like it literally just

SQL updated the orders table through like a JSP that like straightened, like it's not even SQL injection, it's just SQL as a service, right? Anyway. So someone owned them, someone queried the database in the manner of which was intended, using presumably a GUI client of MySQL or PostgreSQL or whatever it was. So someone owned them, stole the order database, Pat broke the story on WhiskeyBiz, and there was some breathless articles by Yuha or whoever in the media about different national personalities, choices in pizza. There are a few actual things in that data set, like some people have put the combinations for their gate, like a pin pad or entry system for their apartment or whatever into the order, like delivery instructions. So it's a little bit of data,

but really, there were some commercials in there in terms of how much cheese they buy, which turns out quite a lot of cheese, who knew? But the interesting thing about this was Pat rang, I think Stuart his name was, the guy who was part of the owner of Hell Pizza, and said, hey, dude, someone's stolen your data. And he said, no, they haven't. We looked, it's still there. Which is hilarious, obviously, like you're laughing, that's great. It's tragic for so many reasons. And also, you know what? Actually entirely reasonable, right? We do this shit by metaphor because we don't know, like, why should a guy that runs a pizza chain know about SQL injections, not injection, about SQL databases? Why should he know about that? It's not

reasonable to expect, that's a totally reasonable thing to say. It's also hilarious. But, so we, and that's the kind of, That's the basis, right, the broken analogy, the analogies that aren't appropriate on which we do things. And we've seen it with legislation, where we legislate based on analogies that don't match. We see it in the militarization of the terminology that we use, where we talk about cyber artillery. Like, denial of service is not fucking artillery. Like, that's a stupid comparison. And by militarizing the terms, we introduce all these other things into our world that we just don't want. And so,

we also defend based on just doing something, right? If we don't understand it, right, as poor Stu from Hell did, if you don't understand it and you go to your tech guys and say, why are people making fun of us on the internet or in the press in this case because they're our cheese, do something for Christ's sake. Like, do you want a job? Do something. And doing something surely is better than doing nothing. And I guess the best example of this would be password changes. right, how many of you, Serena asked already, how many of you work in a place that makes you regularly change your password? Yeah, but that does nothing, that makes

it actively worse, right, we hackers have known this forever, right, the GCHQ finally have updated the guidance that kind of filters down to other organisations, the ASD also I think have updated the guidance, I believe even NZISM is getting on board with this whole maybe changing your password every three months actually is a bad idea, but you know what, I have the actual data, I have graphs, that show a direct correlation between the amount of time you have worked at an organisation and the amount of entropy per password change. I have a graph of it based on active directories from a dozen New Zealand organisations that say, I know how long you've worked in this organisation based on how much entropy your password changes, because this

is absolute goddamn fact. The only problem that changing your password solves is the hacker knows your password. Changing it means a hacker doesn't know your password. The question is, how do you know it in the first place? Like, that's the actual problem. Changing your password really solves essentially nothing, and certainly nothing these days. Another good example is password failure lockouts. If you... So, OK, how many of you have an ATM card or an F-Post card, right? You probably pretty much have one, OK. You understand the concept that there's a four-digit PIN. on your card, right? That's not a very big search space. Anyone who was a phone freak in the 90s is totally cool with dialing all of

the possible combinations of a four-digit number on a pin pad of an ATM. And the way that we solve that, or the way that the people who built the original payments networks back in the 60s, and if you go read the book, Security Engineering by Ross Anderson, he has a really great chapter on the security threat model they considered when they were designing the ATM system, and then with the benefit of 30 years hindsight, how well that fit model mapped onto the fits they actually transpired into that system. If you haven't read Security Engineering, I think the third edition is out now. That is an absolutely excellent book and totally worth reading. But the reason

that we can have four digit pins is because if you have an ATM card and you find it in the street, you go to the ATM, you put it in, you get three tries or four tries or whatever to guess the pin, which is not great. I mean, you try one, two, three, four, a couple of patterns, and then it eats the card or locks the account out or whatever. And that works. That's a great control. The problem is we've taken that control and then applied it to Active Directory. where I have 20,000 users and I want an account, and you know what, I don't care which account. I can try one password versus 20,000

accounts, and at any point in time, five to 10% of your users have the password winter 2017, unless they're very fashionable, in which case it might be spring 2017 by now. It's the latest season's password, you should totally have it. But this is the truth, right? In a New Zealand organisation, it will be welcome one, because that's what Datacom sets in the help desk. Actually, they don't need more, they've kind of got out of that habit now. or whatever other outsourced help desk provider, service desk provider you use sets the default to, which tends to be Season, Welcome 1, Sunshine 1, Sunshine 01 for complexity reasons, uppercase S. So there's a bunch of default passwords,

and I know that. Everyone knows that. Right? Scrape LinkedIn, list passwords, list of users, try one password against every user, right, I've got an account. Right? Because actually that ATM card, that's a second factor. Physical possession of the card is one factor, the pin is the other. Physical possession of an email address, that's not physical possession. That's not a second factor. And that's why ATM style account lockout controls actually don't solve the problem that we use them for. And even more so if you have Active Directory configured such that the count of password lockouts gets reset every half hour. Well, guess what? If it takes me more than half an hour to try one password against all of your user accounts, there is no account lockout. I

just keep going. It's great. And actually, did you know, I learned this the other day, that if you try one of the last two previously set passwords, it doesn't increment the bad password counter, which if you've already got an AD account and you can observe the password count, you can tell by checking the account when you're trying the password. It's pretty cool. Anyway, pro tip for you. And this is where we end up. Thanks, Ad, for modelling this fine piece of equipment. As you can see, the worst light is lit up, and that is roughly the state of defence. In this case, this is actually an offensive box, not a defensive box, so it sucks. So let's talk about

how, now we talk about defense, let's talk about how we actually hack things. And turns out there's quite a lot of ways. Hacking is actually loads of fun. Everyone here is presumably into it. It is a thing that all the kids are doing now. It's so cool. And there are so many fun ways that things can get hacked, right? There's traditional memory corruption exploits, there's time of check, time of use sorts of bugs, there's injection bugs, there's all the rest of the OWASP things, Java deserialization, oh god, that's so good. So many great ways to do it. And all intriguing and hilarious, and you ride the roller coaster of heap exploitation for a week, and

you laugh, and you cry, and you laugh, and you cry, and it doesn't work, and oh god. And eventually it does work, and you feel like a monster ripping up shirt off like the Hulk. I don't do heap exportations, I've never done that, don't worry. Well, only a couple of times. And if you've ever done the Capture the Flag competition, there's all these wonderful bugs and puzzles that people have crafted for you. Capture the Flag competitions are like the crossword puzzles of this industry. It's loads of fun to sit there and work out the little puzzle. And there's a reason why when they recruited for Bletchley Park, they went after all the crossword nerds. It's a really great way to get your

brain going and tease it and have a lot of fun. And there's bug bounty bugs and the sort of bugs we find as pen testers, you know, like missing X-frame options and stuff. So good. Oh, yeah. Maybe even, I don't know, like if you've got some sweet elite NSA Zero Day, right, you can get up there with your Dander Spritz and put some double pulsar in it with a little bit of the old Eternal Blue Screen. Good times, right? Great bugs. What fun. This atom is not me. That's a different atom, don't worry. It's so cool, but it kind of doesn't matter. And that's sad in a way because hacking is loads and loads of fun and we all love to do it. And it's a great hobby. And

it's a hobby, of course, that's been turned into a mill industrial complex, which is a little bit sad. But, you know, basically it doesn't matter how a thing gets hacked. And that's not to say that hacking things is not fun. It totally is, right? It's rewarding and exciting and great. But the thing is, we are building stuff so fast that we have no hope of making our ecosystem of software secure. There is always new stuff being built by developers faster than we as security professionals would ever hope to break it. There's an infinite supply of things for us to go hack. And that's loads of great fun, great job security too. But the thing is, it doesn't matter at a holistic level about how any one thing gets hacked.

Because if you can't hack one thing, but you can hack that thing, and then from that thing you can get that thing without having to do any hacking, well, did it really matter that you couldn't hack that thing? any one individual component of a system is actually kind of not that important. And so what I wanted to talk about briefly as a diversion is that I, to my mind, I think there's two kind of different types of hacker. There are research hackers and there are operational hackers. And research hackers are the sort of people who like to fuzz things or find new bugs or do amazing research or break into the, you know, secure enclave on iOS. And there's a load of really great

researchers that do amazing work. And then there's operational hackers. And operational hackers tend to be, I mean, I guess the evolution of what we used to call script kiddies, people who take other people's bugs and use them in a real world. And those operational hackers tend to think about systems, right, about what Any particular vulnerability or exploit a tool or thing that you've got gets you in terms of an overall system. And operational hacking tends to be less about individual bugs, it's about research, and more about kind of systemic thinking and movement and about being able to move around a piece of infrastructure and understand and answer the question, what does any one individual thing

buy me? And it kind of turns out that actually I'm kind of an operational hacker. My first HackerCon talk, which was at Black Hat and DefCon 2005, was about funnily enough, from Michael Shearer's talk from the cert yesterday about moving down live SSH connections post-intrusions so that you didn't have to hang around a rootkit-a-box. You keep moving through that control master infrastructure that he was talking about. I, in that case, turned it on at runtime with ptrace because there was no config knob to turn it on. But anyway, that was an operational hacking talk, not a research hacking talk. And what I've realised over the years is actually, you know what, I'm a rubbish research

hacker. I've found very few bugs over the years. I mean, I found a few. I have one, probably haven't got time to tell this, but I'm gonna do it anyway. If anyone wants to leave, I'm probably gonna run a little over time, so if you do wanna leave, that's totally cool, I'm fine with that. So one time we were only a thing, and I had spent weeks. This was an external red team, we were breaking into an organisation in New Zealand, and I had spent weeks, and we finally clawed our way in, and I bust into this box, we got a shell, it was like a ginned up through a JSP, Java reverse shell thingy,

And I've been working on this for weeks. Got the shell, posted it into IIC. This time Insomni was me and Brett, so kind of small IIC channel. Posted the shell into IIC. It's like, woohoo, popped shell. Three in the morning, a little root whiskey, went to bed. And I was super excited, obviously, went to bed. And what I didn't do is tell Brett the limitations of the shell that I dropped. And one of the limitations was you could call three invocations of the servlet engine that it was running on because the licensing had expired and it was only licensed for three threads in demo mode which it had fallen back to at that point because the company in question had renewed the license. I didn't

tell Brett that. And I woke up in the morning all like, yeah, right, good stuff, gonna go onwards, move onwards into the rest of the network, show me some Solaris boxes, great times ahead. I get in the channel and Brett's sounding a little sheepish, because we're both working at home at this point. He's sounding a little sheepish. Because Brett's not very good at Unix, right? I mean, that guy is a research hacker, right? And the way the story ends illustrates this. And he had ruined my shell. He'd made three commands. Like, he'd run, like, top or something interactive that was never going to return because that was what he knew about how to Unix. And, of course, I was just, like, catatonic with rage. I don't know that I

actually slashed quit. Maybe I kicked him. I don't know. And those of you who know Brett, it's like nothing Brett hates more than fuck. That guy absolutely hates screwing things up. And he normally doesn't, because it was pretty rare. And he was so embarrassed. And I was like, you know, sulking. And he'd lost the shell. Anyway, he turns out if we rebooted the box, it would come back. And we thought, OK, well, surely. And in this process, of course, we'd broken the production service that was running on this box, which was super important. And many of you have used this service. Anyway, we'd broken it. And so eventually he phones the help desk and says, oh, hi, I'm Dave. I'm a customer of

this. I'm trying to log into my this. It doesn't work. What's going on? He's trying to get to reset it. And presumably they logged the ticket and did nothing. It's a three days pass. This thing's still broken. God. Anyway, so Brett's super ashamed. And he's like, just get me a Solaris box. He's like, just get me a Solaris box. and I will redeem myself. So Shara, bless her heart, went into her test lab work and stole me a Solaris box. It was a Spark box. She stole a Spark box from work, which probably I shouldn't say. Anyway, she borrowed it. Allegedly borrowed a Spark box. Allegedly borrowed a Spark box. Came home with a 1U box under her arm on the bus. And

I plug it in, boot it up. Get a compile environment going, get a GDB environment going, give Brett a shell on the box, explain to him how to use GDB, because he doesn't know how to use it. He's like, what? He's used to Oli debug, right? Windows stuff. And I have to explain to him how he view registers and how he run trace. I have to explain to him how Spark works, like the instruction set. I have to explain to him how the weird calling interface works on Spark with the double stacky thingy. Anyway, so I give him all this and I go to bed and just, you know, sulk. And then he whips out

from first principles a Solaris heap remote and a Solaris stack remote, shells the box and gives me a shell back and tells me to go fix it. And that's the difference between a research hacker and an operational hacker. So a research hacker will pull a Solaris remote out of his ass, having never used a Spark instruction set before. Like, that's a research hacker. I am not that guy. I am the guy that then turned that into catastrophic enterprise-wide compromise. But the thing is, in this talk, right, so this is me at RuxCon 2006 or 2007, and this is one of the talks that kind of kick-started my career in many respects. This is the Firewire podcast. DMA, remote memory manipulation, unlock a Windows

box by plugging a thing in talk I did. And the thing is, that's not my bug, right? That's Tmars bug. I don't know if Tmars here today, he's security at zero these days. That's not my bug, that's Tmars bug. He came up with the bug primitive, and I took it and said, what does it buy me? What it buys me is the ability to read and write remote memory. That buys me, I can unlock a Windows box by plugging into it. And then HBGowry re-implemented it and sold it to the US military for half a million dollars. a hacking team weaponized it and sold it to all sorts of dictators around the world and other

jerks. And unfortunately, that's a, you know, that kind of pissed me off. But what are you gonna do right? But anyway, the point of the story is there are research hackers and there are operational hackers. And they are kind of a different thing. And the real, I think, the thing that defines being an operational hacker is asking, what does this buy me? Because systemic thinking is the key to being an operational hacker. And that's how things get owned. And by things and by people, I mean corporations. So let's go. Let's talk specifics. How do you hack 70% of organizations? And by this, I mean like businesses over 500 people. So I mean medium to large enterprise. Or agencies

or whatever else. How do they get hacked in New Zealand, in my experience? Well, it goes something like this. Ooh. Oh, yeah. So I get my little boat, right, and I put it on my chest. Okay, initial interface. This is how it goes. Step one, find something that is single factor. Step two, obtain a credential for that single factor thing. As Pipes said, hackers love getting creds and owning things. So, find something to own, get the cred, log in. Or, if you're feeling kind of fancy, you could phish for code exec instead of phishing for credentials. But, okay, that's phase one done. So, phase two is get domain admin and keep it. And that's, okay, that's a little bit of actual hacking. I

mean, there's a bunch of ways that we do that. Pipes talked about some of the defensive options that you can use, but there's a number of ones that we use fairly regularly. If you're not familiar with the Kerberos attack, that is a mechanism by which any domain user can obtain essentially a hash of any service account's password in the domain, and then they can offline crack that. In particular, you're looking for services that have a Kerberos service principal name allocated and are not a managed domain account, so they have a regular human set password. That process of offline cracking is by design. It's not going to get fixed. The only defense is to have every... Active Directory account, which has a Kerberos service principal name associated with

it, have an uncrackable password. That is the only defense that you have, other than maybe logging, that people are requesting Kerberos tickets in a weird way, but that's kind of normal behavior. You actually have to do those things, make sure those credentials are completely uncrackable, which is hard. Another technique we use is go look for the password. One of the common places to do that would be the group policy files that hang out in slash sysvol on your domain controller. Go parse all the XML files. There will be encoded reversibly of the SCADA passwords in there. Most often those are local admin passwords for machines. You parse the XML files, you pull those out, now you've probably got local admin on a bunch of different machines. It can

be difficult to figure out which machines those policies apply to or how historical they are, but almost certainly you'll find something. One of the techniques we've had a lot of fun with is if there is a writable share on the network, which let's face it, there is, and you've got a one domain account that can be used to authenticate it all, so you've got your first account, you can go drop files in those directories that will cause anything, any machine which browsers through that folder in Windows Explorer to attempt to connect to you. One of the common examples of this is the .scf file, which you can put like a URI Windows domain URI into like the location of the icon for that particular folder and Explorer will

go and connect to it and if you prompt for a net NTLM authentication process you get a net NTLM challenge response that you can crack offline and get the credentials for if that is net NTLM version 1 which is quite common still you can 100% key space for offline crack that on our cracking rig that's two days full so on average one day to take a net NTLM challenge response off the wire and turn it into an NTLM hash that you can then hash pass. That's the way that we have you, which is a lot of fun. And of course, if you want to do super easy mode, you go to the SharePoint, you type in security review report, and you read your competitor's security review reports, and inevitably

they've found all the ways to get to Manhattan, and then you go do it.

We find the risk register, right, and go read what they did. It's great. I mean, we know how to use SharePoint. It's not fun, but we know how to do it. There's a reason Pypes is called Network Ransack. He loves reading your SharePoint. That guy just lives for SharePoint. You can use Oday. Obviously, there's lots of other things you can do to get domain admin. Your antivirus is going to give out domain admin, and your backup system is going to give out domain admin, and, you know, every other piece of rubbish enterprise software, everything written in Java, all of your Unix boxes that are domain integrated, they're all gonna give away demand habits. There's lots

of fun ways to do it, but there's like four or five techniques that most people use and have a playbook for using reliably, and they understand what logs they're gonna leave, and they understand how to do that. And the end result, I guess, for an attacker is, That's a 20 minute process in some cases. From initial entry to I'm gonna go get the main admin through one of these playbook things. And as Pipes said, if you can make us deviate from our playbook, we have to stop and go lab it up and make sure we understand how it works. And that means it goes from 20 minutes to a week, right? Because now Ross has

to go figure out how to use the Windows update WSUS thingy that you did. Like that was pretty sweet, but it took him. He went away for the weekend, labbed it up at home in his spare time, came back, we used it on Monday, we got the main admin, good times. That slows us down, otherwise we would have been done in, you know, having domain admin fried chicken, which is good. Now, we have a, the policy is, like, you get whiskey for the root, but that's kind of out of date these days, so these days you get domain admin fried chicken, it's pretty good, pretty good. And then, okay, so you get domain admin, what

you do, what do you do then? Well, you want to keep it, and the first thing that we do, and indeed everybody else does, is you go steal the entire Active Directory data. The old way to do that was you logged into the main troller and you ran volume shadow copy. You made a shadow copy of the NTDisk directory, NTDisk file, you copied the shadow copy off, you remove the volume shadow copy and then he went offline cracked it. That's so last season. The cool new way to do it is to use the domain replication protocol. We just say, hey, I'm totally also a domain controller buddy. Can we just kind of replicate it? And

that saves you having to pass the NTDisk.dit, which takes forever. And it's super easy and convenient. And Mimikatz implements it. And Impact implements it. You can run it on Unix. You can pass the hash to do it. This is literally 15 minutes to exfil your entire ID. And that means all of the current users, all of their current passwords, all of the previous password histories you stored so that we can crack all of those, map out every password change, and we know what passwords you use is going to change it to in the future so that you can never evict us. We still have the Kerb TGT, which is the thing that's used to sign

all of the other Kerberos tickets in the environment such that we can now forge Kerberos tickets that last for 10 years that are still valid even after you've changed those credentials that we can then use for the rest of time to access your network. And that's what everybody else does. And then phase three, is action on objectives. So, pipes reads all of the tedious SharePoint, we identify what the business target is that we've been told to go after, we find the poor salaryman whose job it is to do for a living, and we watch him do his job for a week, or two, or three, as long as it takes to understand the business processes that go around the thing we're trying to nick. So if we

want to do a swift funds transfer, we find the swift funds transfer clerk, we hit print screen for a week, watch them do their job, We read all the documentation in the SharePoint about how their job works. We read the slide deck that they use to indoctrinate new staff members about how to do their jobs so that we understand too. We watch them do their job for a while, then we wait until they're not there and we do their job for them. There's probably an intermediate step where we understand how the auditing works and how the SWIFT funds transfer audit process works and where the printer is. Then we have to write this thing that

shims the postscript and edits the line out of the print job of the audit report so that it doesn't get printed out on the printer. Then you man in the middle of the print jobs, rewrite the postscript, send them on again so no one notices that. But this is what you do. You find the person who does it for a living and you do their job for them while they're not looking. Maybe you go play with a scatterhide to my, maybe you transfer some funds, or maybe, maybe actually your business target is in another castle. Maybe you get there and it's not actually there. It's outsourced. It's in another domain. It's air-gap. Maybe they've got privileged admin workstations and you can't get them in admin so easily

and you have to go do something else. But that's cool. We started somewhere. Maybe we have to go to another data center. Maybe we have to go through another air gap. That's cool. I'm down with that. That's fine. We keep going. Because it kind of doesn't matter when you hack everything. Now, okay, some people are going to say, oh, you said find a 1FA thing on the internet. We don't have any one of things because we use multi-factor auth for everything, even Office 365. We pay the extra $6 per user month to have multi-factor auth because we are high rollers, right? And we do a good job. And you, Mr. Hacker Man, like you're just talking about other people who don't know, you know, who do

a rubbish job at security. We are better than that because we actually understand and we're at this conference. That's cool. And that's great. I'm really happy that you are paying the extra $6 per user month. for multi-factor on Office 365, good for you, you can buy me a beer later on for being such a high roller. We have dedicated admin forests, privileged admin workstations, we have air caps, we have all these wonderful things, that's great, that's cool, you're in the top 1%, go you, you did your job. But you don't work in isolation.

You can't buy hardware that isn't made in Shenzhen. Maybe someone who works in the US government can buy from the one Dell factory that didn't burn down or whatever in Texas. No one else can buy hardware that's not made in Shenzhen. Your hardware supply chain is People's Republic of China. Well, maybe Korea if you buy a Samsung phone, but you wouldn't want to do that because you can't patch it. You and everything else in this country exist in a technical and business ecosystem. And I get to look at that ecosystem and go, what does a telco buy me? What does a datacom buy me? What does IBM buy me? I get to look at the whole ecosystem. What does GitHub buy me? Right? Those of you who are

old enough to remember SourceForge being a thing would have asked what is SourceForge buy me. Turns out lots of stuff. We get to look at the whole thing because there's a thing called supply chains. You don't do all of the things yourself. Right? Even at Google scale. with Google money, they can't build everything themselves, and that's why Darren spent so long working on software supply chain as a problem at Google. And you have to look at your supply chain. And in fact, your supply chain looks at you. If you go to a New Zealand business and you say, do you guys think that you are a target because of your customers? Most people, like risk guys, are going to be blank-faced. But the reality is these things exist

in a continuous ecosystem. And we get to, as an adversary, choose where in the ecosystem to attack. and then we move up and down the supply chain at will. And that's not just me, right? This is what real adversaries do. When the Mossad saw something hinky happening on a box that had Kaspersky installed, they saw it rummaging around looking for secret stuff, did they stop and reverse engineer the antivirus agent that Kaspersky used on the desktop system they're looking at? No. They went, well, let's just go home Kaspersky and see who's in there. And they did, right? Because YOLO, right? Who cares? No problem. Easy done. So they go on Kaspersky, turns out the Russians are in there looking for NSA staff, sweet, no problem. When the NSA and

Mossad again wanted to go after the Natanz Nuclear Enrichment Facility and they needed some SSL certs to sign their malware, what did they do? They went to Taiwan and nicked it off Jmicron and whatever the other company was they nicked a cert off in some business park in Taiwan because they don't care. YOLO, right? If you wanted to know, I don't know, who was visiting the European Parliament and what they were doing there, Let's just go own Belgicom, right? Get in the middle of some mobile data sessions, get in the middle of some roaming, we can watch people roaming on and off the network, which is what the GCHQ did. If you want to know what Greece is doing to prepare for the Olympics and what the

concerns about terrorist attacks in the Olympics are, well, let's just go own Vodafone Athens and backdoor the Ericsson switch that runs their cell network to send, to use the lawful intercept interface, to send a copy of the Prime Minister's phone to the NSA.

and then the Vodafone security guy killed himself and that really sucked. Or,

if you're a Chinese APT called Cloudhopper, maybe you go own a bunch of managed service providers. Now this is a screen grab from the Cloudhopper report document published by PwC and BAE, joint research by them out of the UK. This followed an APT campaign primarily in Japan. which owned a large managed service provider, specifically for the point of going into the downstream customers. They owned the MSP, they went through the MSP, through the regular administrative interfaces that MSP uses to manage the customers, went into the customer, found the data they wanted, exfiltered it back out through the MSP and off, up into the attacker. This was the cloud hopper paper, well worth looking into. And this applies to systems integrators, to telcos, to software vendors, to GitHub,

to the Node, NPM, repositories to Debian, to Ubuntu, the supply chain is huge. If you actually went through and enumerated every piece of code, every system, every upstream that all your stuff relied on, you would find that is a very very big list and it's not unreasonable to suggest that owning any one of those things anywhere in that supply chain is sufficient given enough time to pop somewhere and move through that infrastructure, through that software into your environment, no matter how good your six dollars a month worth of MFA is. And so I asked myself, well in New Zealand how many people manage their own domain? How many people do all of their own infrastructure themselves? So I asked the DNS, like how many MX records

point to gni.co.nz? Something.gni.co.nz? Turns out quite a lot, good work. How many name server records point to a datacom name server? Turns out quite a lot. Same with mail. DMZ Global, now they have done a lot of mail for a lot of important people over the years in New Zealand, now part of Vodafone. Encapsular, how many New Zealand government domain name records point at encapsular? Turns out basically all of them because, you know, CWP. Good work, madman. Top stuff. And the question I find myself asking looking at this is, who's Liz?

Do you think that anyone told Liz on accounts payable at Datacom that she personally is a target for 2,000 high-profile domains in New Zealand? Do you think that her workstation was specifically hardened? Do you think that she opens PDFs in a sandbox? Do you think that anyone gave her special user training? Do you think anyone made sure that her password was good? Do you think that Liz knows that she personally is a target for our national security? I googled, right, I googled to check where Liz is. There's actually no mention of Liz, she doesn't have a LinkedIn, I don't know who she is. I asked the people who work with Datacom if they knew Liz from accounting. They don't. And then where's Alan these days?

So Alan Manson is the technical, is the admin contact, the registering contact for Datacom.CodeNZ. If I can take over Datacom.CodeNZ, I can reconfigure their name servers, I can reconfigure their mail, the MX records and I can get in the middle of everybody's mail and then I can password reset every other account that's password resetable via email and I can probably own the entire New Zealand government. I don't think it's on, that's not an unreasonable thing to assert, right? So the question is what's Alan up to these days? Turns out I don't think Alan works at Datacom anymore. He did for a long time, right? He's been there, what, that's 36 years at Datacom, like that

guy gets the long service award, good for him. As far as his LinkedIn says, he now works at Fletcher Building. the end okay I am going on NS records and who is records now it may well be that this mailbox has been forwarded to soa at datacom.com and all of this is amazing and wonderful but as an attacker I don't yet know that and is it worth my time to go pop fish Liz and Alan and find out what does it cost me to fish two people I get a pretext of virus total great easy run up a fish inside great easy fish me some Winter One or some Welcome One or some Sunshine One or whatever, try it against some single factor thing. What's that going to

take? Everyone in this room could probably do this before the end of my talk. I'm not suggesting you do, obviously. But that's what, as an attacker, I ask. And I spend all goddamn day thinking, well, what's Fujitsu up to these days? Oh, OK, Fujitsu's technical concept is, wow, does anyone remember Domain? They were the New Zealand registrar back in the... I wonder what they're up to these days. Oh, that's right, they got bought by Melbourne IT. Yes, that's right, I remember now. For a brief refresher, that's Domains, the people you bought Domains off back in the old days, that's what their website used to look like, it's quite a beautiful thing. This is 2004, about

the time they were acquired by Melbourne IT. What are, what are Domains are up to these days? Turns out, they do manage social media advertising. Do you think that the managed social media advertising team at domains.net.demonz know that every high-profile domain that was registered 15 years ago in this country depends upon them not getting owned. Do you think they know that? I don't think they do. I would be surprised. Now, Melbourne IT, of course, has a long and proud history of not getting owned. So in 2000, what was this? 2009, a bunch of Turkish script kids owned domains and jacked a bunch of high-profile domains in New Zealand, Coca-Cola, Windows Live, with anti-war propaganda, right? Perfect example of a supply chain attack. Do you think that after that, Domain's

got the message or Melbourne IT got the message? Well, it's 2013, Melbourne IT gets owned and the attacker uses it to deface the New York Times. Because it turns out Melbourne IT actually is a huge massive web of domain registrars and it's actually responsible for a fairly significant portion of the world's DNS infrastructure. In fact, if I remember rightly, are they the Are they the registrar for the edu route? Because somebody jacked .edu, like the top level edu domain, and I think maybe that was a Melbourne IT one as well. So yes, Melbourne IT, the people who got the New York Times owned. And every time they get owned, it seems to be because ColdFusion. This was one of the breaches where they got owned, well,

let me put this clearly so that their lawyers don't say anything. They hosted a box which ran ColdFusion, which they did not manage because, okay, so the customer thought they did, and they thought they didn't and the customer was AAPT which at the time was owned by Telecom I think. Or maybe it was just very after you unloaded it, in this case good job. They got owned through ColdFusion. So this is the people who got us owned by ColdFusion. Oh, and then two days ago this happened. The NCSC published their 2016 and 17 period unclassified cyber threat which summarizes the things that the NCSC, which is the spooks, have seen in New Zealand in the last year, and they talk about

what the specifics are. And this is their section on supply chain. The NCSC became aware of suspicious activity from a New Zealand subsidy of a global organisations network. The organisation provided services to a wide range of organisations of national significance. The NCSC worked with the organisation to investigate the activity, identify the presence of two malicious rats on a server in New Zealand. recovered evidence of password dumping and lateral movement which is so many cats the presence of these tools indicated scope of the compromise was likely wider than a single server this was attributed to a foreign intelligence service that's cool I am glad that the NCSC and therefore GCSP agree with me that's nice they say supply chain is a

problem in New Zealand I've talked to blue team people in Australia and New Zealand who have rolled a more than one intrusion from a managed service provider into their customers in New Zealand in the last year. More than one. Several, I might say, even. And that's really good, because this is a thing that we are here to talk about. It is a supply chain and systemic thinking. Now, it is really good that the GCSB is open enough to publish this kind of information and tell us that systems of national significance were owned through a global organisation's network. That global organisation's Deloitte Best I can tell, I don't actually know. But what do you think, right? So Deloitte got owned.

Deloitte's domain admin got popped. Have a think about that. Do you know what that means? How many of you have ever recovered from a domain admin level compromise? No one puts it in hand because no one ever has, right? You never evict an attacker after that. Obviously this talk's been recorded and I don't mean this, but man, they are I don't mean it, allegedly fucked. The password history for every Deloitte employee probably, allegedly probably, just got nicked. The password change process they probably just did to adjust their security posture that the bureau just reported on, I don't think that works because attackers know how people change their passwords. They're going to increment the number on the end. Did they roll the curb TGT? about all of the 10-year golden

tickets that got issued with the stolen curb tgt evicting someone who has domain admin in a global organization without building an entire parallel copy of your global organization has anyone seen a second deloitte kicking around now have a think about what that means for supply chain how many of you use deloitte for something exactly buddy right so even though all of your mfa on the internet is wonderful and you pay the six dollars you use a month

And this is what the real world looks like to an attacker. I am not picking on a single vendor. I have said bad things about Datacom. I've said bad things. Well, I didn't really say anything bad about GNI, so my apologies. I can say a bad thing if you want. But no, and I've said bad things about Deloitte. But honestly, for you, and I don't know if there's any Datacom people in the room, honestly, you guys have a serious market advantage right now because If I go to a customer and I say, yo dog, I think I should be able to cross the boundary into your managed service provider as part of this pentest, as part of this red team, and your service provider in this case

is HPE or IBM. IBM's revenue last year was 180 million US. New Zealand's GDP was, actually I was going to say market cap's 180 million. New Zealand's GDP is 185 million, right? We are not a big customer. we have no leverage so against GNI and Datacom you have leverage over him that's good between the two of you could sort the shit out right but if you go to HPE or whatever they're called now you are not going to be allowed to get the main admin so I think whilst I'm criticizing some vendors I think you guys this is that your chance to really make some hay right here

this is just how we think as attackers I look at that ecosystem I observe how you choose to defend, how you choose to assemble your solutions, how you choose to assemble them out of cloud components that you have no visibility of the internals of, and I get to choose where I attack. So, you might ask, quite reasonably, what do? What indeed do? What indeed? Squirt water my face apparently is what do.

So obviously there is some technical frou-frou, right? There's stuff you can do. You could trueify all the things. That would be great. You could trueify Office 365. That would be great. You could think before you bolted ADFS that integrates your AD into Azure into your on-prem AD. You could think about that before you do it. That would be grand. And you could stop pretending that your corporate Active Directory is fine, right? It is not fine. It is a trash fire.

I think that's a reasonable thing to say, right? Everyone's AD is a trash. because they were built to deal with problems that we had 15 years ago. Microsoft to their credit have done a good job, right? They actually do care about making this stuff work well, but no one's building a new environment. All of the things that are going to get you owned, telcos, managed service providers, upstream software vendors, GitHub, okay maybe GitHub doesn't have an AD, maybe they do, I don't know. All of those things are built on Windows tech stacks that are not going away and will be like this for the foreseeable future. So I think fixing everyone's AD is probably out

of the question. We can at least detect stuff. We can, there's a bunch of stuff, Pipes talked about, things you can do in terms of monitoring your AD logs to look for signs of lateral movement of things happening. You can structure your AD such that you do have separate, physically separate workstations for admin in a separate forest. Forest trusts don't really work either, sorry. You can do some of this technical stuff, but fundamentally it kind of doesn't matter because we make these choices because we have bad risk data. When we deployed Active Directory for big organizations 15 years ago, when it was what, NT4 probably, we did not know that this is where we would

end up. We did not know that Windows Kerberos was gonna bite us in the ass so bad, because it worked so well on Unix. We didn't know because we have bad risk data. And why do we have bad risk data? Because we don't actually test anything. And we make these decisions in a vacuum without any data.

We have built systems that are untestable. I don't mean technically untestable because I can take a piece of software, I can reverse engineer it. I can look at a network diagram, I can read some configs, I can look at the technical makeup of your systems and I can understand how they work. In the case of cloud stuff where by design you are not supposed to look at how the cloud sausage is made, okay, I can't look at the internals of Amazon's environment, right? I'm not allowed to go jump up into the hypervisor and go have a peek. Unless you have some sweet zen-o day like in that other talk. In which case, you should totally

go look and let us know how it is in there. Allegedly, have a look. But what we have built are systems that are commercially untestable. When you outsource your domain admin to Fuji or HPE or whoever else, is Solnet still a thing? I can't remember. Solnet's apparently still a thing. When you outsource your domain admin, you do not outsource the right to go test it. When you get someone else to be a managed security operations center to read your logs and respond to incidents, for some bizarre reason that escapes me, there is no right to actually go drill and exercise that built into the contracts. What the actual hell? When you buy a piece of software, it specifically says in the EULA that you're not allowed to reverse engineer

it. What is this is nuts. We have built systems that we are unable to test commercially. Now, first hacker con I ever went to was Black Hat Singapore in 2001. And I went to a talk, and the person talking was the keynote. And he said, we are, by building the software dynamically at runtime, by assembling software dynamically at runtime out of components, we are entering into a situation where any particular instance of that software might be a configuration that we have never seen and never tested. How the hell are we going to secure this? That was Bruce Schneier, 2001. He's talking about ActiveX in Internet Explorer and dynamically assembling components out of com. Now, whether we talk about dynamically assembling Java things out of ridiculous amounts of XML

files at runtime, or we're talking about assembling things out of microservices based on some crazy hipster continuous integration stuff, or something super agile where we assemble it out of whatever we checked into Git five minutes ago. We are assembling things that we have never seen before. And I think that's really interesting that, well, how did ActiveX and Internet Explorer turn out? Well, if anyone's wearing the Insomnia shirt with the VMware exploit, that's an ActiveX control on the back of the shirt right there. We have systems that are untestable and by integrating all of this stuff together with no visibility, no insight into when things happen, no ability to roll a response. Now some of the

cloud services do have a pretty good logging infrastructure, Amazon Cloud Trail, Google has a bunch of really good logging available in the G Suite, but by and large if your cloud provider or your service provider, your hosting provider or your managed service provider or your SOC provider gets owned, do you think they're going to tell you? No, they don't. And even if they did, they're not going to let you roll a response either. Do you think you can roll up to Amazon's data center and say, hey, I would like to forensically image a disk? OK, OK. A, they're going to say no. B, they're going to say, look at the biometric system on the door.

You can't even get in, buddy. Three, there isn't a disk, right? This is the network as a computer, as Sun would have had back in the 2000s. We don't even know where the data is. Like, is it in Hong Kong? Is it in Sydney? Who knows, right? Because magical cloud stuff. We can't actually even roll a response on this stuff. And this is how it goes, right? When I go on to the sales call and the customer says, please read TMS, and I say, that's cool, that's cool, who manages domain? And they say, AEDS, I'm in HPE, I'm in DXC. And I say, okay, cool, I can go own HPE or whatever they call, right?

And the customer makes choking noises because legal is just going to die, right? You think HPE is lawyers? DXC, sorry, I'm sure they rolled in the lawyers from Computer Sciences Corp or whatever. Do you think that they have, like we are just a fly to SWAT, like our entire country is a fly to SWAT for them, right? I mean, it's just not happening. And eventually, eventually we are going to have to surmount this because this is the actual problem, in my humble opinion, of breaking into people for the last 15 years. This is how people get owned. It's supply chain. A, we can't even identify a supply chain, but B, we actually cannot get any data about security implications of our supply chain

how good is github can you imagine github getting owned can you imagine like how much stuff you could pop if you own github right now all that slack can you imagine popping slack like how much stuff how many git builds could you trigger from owning slack that would then continue as integrate out in the pro can you imagine how much stuff like how sweet would that be right And surely it's not happened, but I don't know, right? I haven't rolled a response there. Have Slack told you they got owned? I don't know, right? I think they did, didn't they? They got a little bit owned, I'm not sure. But we have to, right? We have

to surmount this. So when Nmap got owned, how did they get owned? They got owned because they hosted their source repository on Linode and the attacker owned Linode and popped up into their VPS and charged with their source. is a thing that Black Hat's been doing forever this is a thing that nation-state attackers are doing right now this is a thing that we inappropriately recompensed we will also do for you that's nice the good news and I'm not really into that much the good news is actually this is starting to happen we are starting to get engagements with our customers where they have gone away and talked to their service providers and said look I shit's real like this is happening not in some overseas country

this is happening here in this country right now and we actually need to understand the scale of the problem we've got so how are we going to do this and it turns out based on a few recent engagements and stuff this is actually achievable within the bounds of our commercial relationships within the technical bounds of our systems right there are ways to do this but people don't realize this is the thing they need to test right the web apps are all the other bits and pieces on your external perimeter, sure we can hack them, right, and we should still do some project-based pen testing of those systems, but when a nation state adversary wants to

bust in, they are going to look at your telco that provides the WAN links that ties all your offices together in the clear because they sold you a VPN when what they meant was MPLS, which isn't a VPN, it's a virtual network in the sense that it's virtual but not private in the sense that it's encrypted. They are gonna go pop up in the telco and just go, shazam, in your WAN.

But I need your help that when you go out to get the next round of security testing that you have been and talk to your vendors. And next time your vendor comes to sell you something, ask him, how are we going to test it? And not just the product. I don't mean test the IDS sensor. I mean, where do you log into the IDS sensor from? Oh, the jump host. OK, we're going to test the jump host. Where's it from? Oh, you're a corporate AD. Can we test your corporate AD? your corporate ID logged into? Oh, remote access via VPN. Who has access to your VPN? Oh, your vendors. How do they authenticate? Oh, two-factor

via SMS. Okay, how do we deal with number portability? Let's go talk to the telco about attacking the number portability system too. Okay, sounds hard, but this is a thing that we will do because what's the alternative, right? We have to make risk empirical. We have to make decisions based on how we actually get owned, not our boats flipped by the Da Vinci virus. We have to look at what the attackers are actually doing, this is what they do. Because okay, right now what are our options? Our options are we can pretend that audit and compliance works, right, we should say the status quo. We can ISO 27k ourselves to fund and profit. We can enter ISM, woohoo, good times, good times.

We could buy cyber insurance and honestly This will actually probably get us through the next five, ten years because I mean the insurance industry kind of aligns with what we need, like they don't want to pay out, they want to pay out a little bit, like their business model kind of aligns up with what we need and this will buy us maybe a few years, I don't know. The times we've been involved with cyber insurance jobs have tempered my enthusiasm for the subject a little bit. Turns out they're not actually that keen on paying out, who knew? The third option is we can have what Declan I'm sure is about to get up here and announce, a vigilante unsolicited national bug bounty.

So when you're driving down the road and you just picked up a hitchhiker who's a foreign tourist who's visiting our beautiful country and you see a possum on the road, it is your instinct as a New Zealander to swerve and run over the possum. Of course the foreigner who is in your passenger seat will scream, and go, what are you doing? You ran over the cute fluffy animal and you will explain that it is my duty as a New Zealand citizen to protect our forests by running over opossum. It is my cultural right to run over opossum to protect poutacara trees. And at some point, someone is going to get it into their head that

it is their cyber national duty to cyber swerve to hit the cyborg opossums to protect cyber poutacaras. And they will see a system of national importance that is rubbish and they will go own it. and they'll go, hey, look, I totally own this thing. And maybe the herd of health of our systems would improve. But I'll let Declan detail this program with more specifics. I'm sure the rewards will be very generous. I'm not advocating that, by the way. Allegedly, someone might decide. We could wait for the good old-fashioned cyber Pearl Harbor, which is what we're going to do. Or we could hope, which is what I'm doing right now. This is starting to happen. We will

get on top of supply chain because we must. Hope, are you going to sell us on this Barack Obama rubbish? Yes, hope.

And I'm not normally big into this whole hope business. I'm more of a doom and gloom sort of cat. But there is. If you'd asked me this two years ago, I would have said, no, it's totes fucked, mate, totes. Maybe not in that exact word, because I'm not a millennial, you know, sweet young millennial thing, like Alex would say. Is totes a thing that millennials say, or is that like the ones before? I don't even know. I guess the reassurance I wanted to give you, we had a lot of talk about mental health in the last couple of days, and honestly, crushing nihilistic despair is a kind of a sign that you understand information security. And so I'd like to offer you this

to finish with. I guess there is some reassurance, right? Because people must in fact actually be all right. Because anyone who actually wanted to turn the power off

And I haven't. So, you know, got that going for me, right? It's kind of nice. So yeah, don't forget to go outside sometimes, you know. Look at the forest.

Forget about computers for a bit. A bath from the death metal band, black metal band, Immortal. exploring the forest as you do for inspiration. So yeah, go outside. Try not to think about this for half an hour or something. You'll feel better. I mean, it'll still be rubbish when you get back, but you know, you would have seen some trees and stuff. And yeah, that's kind of me, eh? Thank you very much.