BsidesLV 2025 - PasswordsCon - Tuesday

[Music]

[Music]

[Music] by [Music] 3. [Music] Hey. Hey. [Music]

Down. [Music] Down. [Music]

[Music]

Heat. Heat. [Music] Heat. Heat.

[Music]

Heat. Heat. Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat.

[Music]

Heat. Heat. Heat. Heat. [Music] Heat. Heat. [Music]

Heat. [Music]

[Music] Heat. [Music]

[Music] Heat. [Music] Heat. [Music]

Woo! Wow! [Music]

hear people. That's all right. >> Okay, >> cool. Let's do this. >> I think that microphone's off. >> Let me turn it on for you. >> There you go.

>> Okay. We'd like to welcome everyone to our second day of Passwords Con. Uh it's been going very well so far. It's nice to see the room so full as well. And uh as Dustin mentioned, remember to hydrate with some something that's preferably got little to no alcohol in it. Just want to thank our sponsors, Diamond sponsors, Adobe and Aikido, and then our gold sponsors, Formal and Drop Zone AI. Then a reminder about cell phones. just please put them on silent so that when Dustin's speaking we don't have phones ringing or worst case Baby Shark playing as a ringtone or something like that. >> Yep. >> And then um also when it comes to taking

photos, Dustin doesn't mind you taking photos of him or of his slides, but obviously adhering to to the besides policy, not any photos of any of the attendees without their consent both in this room or anywhere else. So we can get started. Um I'm trying to think sure I think I know Dustin Evil almost 10 years now. >> Yeah, sounds like >> 10 years now. And uh when it comes to cracking passwords, algorithms, working with Hashgad, working with anything to do with uh what Passwords Con's about. I think Dustin's one of the most authoritative figures that we have. So you're going to learn a lot today. So pay a lot of attention. It's great that

he's here to give us this talk. So without further ado, we're going to hand over to evil monk Dustin. [Applause] >> All right, good morning everybody. Um, this talk was interesting. U, we'll get into the fun stuff here intro in a second. So obviously this is F5 load balancer service account decryption. Um, an F. Who here knows what an F5 is? Excellent. You're all in the right room then. So who am I really? He already went through a bunch of it. You know, I collect black badges, church of Wi-Fi. I'm a senior technical staff member. At one point, I used to be a network engineer, and that's the important part. I used to maintain, build, and manage

F5s for a living for a bank. So, that's where this magic comes all about. And obviously, if you want to find me on socials, I'm evil_mog on Twitter, evilmog on LinkedIn, and then mog.evil.af on blue sky. And yes, I had to go bribe some people to get an Afghanistan domain name. That was a whole different story. So what is an F5? This is the important part. An F5 is a load balancer. So what does a load balancer do? It takes packets in, presents a virtual IP out to the world, and it dispatches things in the back end to alternate servers anywhere from layer 4 all the way up to layer 7. And they can do funky mangling.

They can do similar stuff such as uh what's engine X. In fact, engine X is now owned by F5. So it's kind of cool. The F5, the important part, will store credentials. um things like LDAP for example are stored in there. So say I need to go authenticate users talking to the F5 or talking to the application against active directory. I need to store a LDAP bind password. So who here remembers 2022 when all the F5 started getting popped? Who here had to work IR cases on that? Probably a few of you. So the question came up, if someone pops an F5 and has a full disk image or command line injection into an F5, what can they

do with this? Well, the cool part about this is actually back in the cool part about this whole thing is you can actually get service account passwords out and do dirty things. But anyways, the important part back to my little slide deck as I go on a divergent rant. um you basically hide servers behind a virtual IP and a pool and a lot of these functionality requires what's called local traffic manager and then APM whatever that stands for gives access to do advanced mangling. So anyways F5s are always installed in pairs. You have an active, you have a standby and they need to be able to transfer their configurations between the two including their encrypted data

back and forth. This is why this attack even works in the first place. The F5s encrypt their stored service account passwords in their configuration file. It's like dollars m dollar sign uh two character salt dollar sign and then a bunch of base 64 characters which I'll show in a second. Now F5s have a master key and a unit key. So the unit key in the case of a physical device is normally stored in the EPROM. They don't persist it to the file system. In the case of a virtual device, they store it on the file system. This unit key encrypts the master key. I know it's weird with AES 256 electronic codebook mode and that's how you can retrieve the

ma the master key out. So the unit keys are unique to the F5s. The master keys are unique to the configuration pair. Um and you typically install them in pairs. And so then you use that master key to encrypt the c the configuration passwords. Now the secret that no F5 tech will tell you but it is actually documented barely is there's a command called F5 MKU. is designed for manipulating the master key files. This command is documented. The uppercase K flag is not documented except for in one very tiny thing for synchronizing master keys between units when you're doing an HA recovery. If you go type the help command as an example on an F5

F5 MKU help, there is no dashuppercase K even mentioned in the command file. But if you type F5 MKU-K as an example, there's a B 64 configuration key. So this is how we can go do some very nefarious things. And by I talked to F5ERT, they're like, hey, this is okay doing the talk. They're not really revealing anything public or not public. We're just, you know, you're making people aware that if a service account password on is it stored in an F5 and your F5 gets popped, please just rotate that service account password because it's been compromised. It's that's the whole gist of this talk. So anyways, the next part we're going on to, as you can see here on this command,

and that's why it went to black and white on white doesn't look that great. So for the password extraction, we use this really cool command. So in F5, it has two shells. You have bash and you have what's called TMSH, the traffic management shell. So from a bash shell, you can run TMSH commands. So F5s have these things called partitions. So I can store like a partition for one app, partition for another app, and make an F5 appear as multiple partitions. If you compromise one, you can tell it show me all of the commands for a partition for example, or just give me the that's what the recursive is on that show running configuration. Let's see everything in

an F5, which is great for when you're doing a compromise assessment or running a red team. So what that looks like here, I'm going to make this easier for you guys to see. Oops, wrong one. Aha. So what we can do is we can actually GP for service account passwords right from the command line. So we're doing tmssh quiet c you know cd into the root directory show the running config recursive and then gp it for dollars m dollar sign looks something like this. So when you're looking at um there we go here is like an example of a bind dn and bind password. It's a dollars m dollar sign a two character salt and then base 64 encoded.

You know fairly easy and straightforward. Now, the cool part about this, the decryption is relatively simple. So, pardon my terrible color coding. I tried to do this because I don't like using pointers. So, you have your dollars m dollar sign, your salt, B 64 encoded. So, you take the prefix. We're going to remove this later, but you store it for in your script to go strip it out. You then base 64 decode that string at the end for the dollars m dollar sign. That gives you the raw bytes. Grab your um the AS key using F5 MKU and this is AES 128 electronic code book. Every Python library speaks this. OpenSSL speaks it. Say B 64 decode your AES key. Decrypt

the cipher bytes of the AS key. Remove QD from the decrypted password. That's it. That took me, you know, a little bit to go figure out, but it wasn't terrible. So, the example now it's demo time. Let's see how great my demo skills are today. Um, Python 3 F5.py. So, we're going to grab the master key from this box. F5 MKU-K. And where's my cursor? Oh, there we go. Found you. It's the only curse of doing light mode. So, we're going to paste you. Oh, come on. Command V. Now, we're going to grab the encrypted password. So, in this case, let's grab Oh, this is also handy because you can decrypt the uh keys used to go talk to

F5 to go pull firmware updates and other status updates down as well because R5 gets their own. So, if you want to do some research later, bonus research activity. Anyways, we'll go copy you. You're going to copy you. And congratulations evil Mog besides LV 2025. Now the other way you can do this. [Applause] Thank you. Thank you. Now the other way we can do this if I remember correctly we can grab the unit key out using some entertainment. So here is the unit key. Um it's just stored in hex on the box. It's on the config big IP K store unit key. We're going to copy you. Ah damn it. I can't type today. And there we go. Copy. So I have another

tool here. Python 3. One sec. I wrote this tool like on the plane. So I apologize. We put our unit key down that I just copied out and the master key and it will give you the output of the M5 MKU. I discovered this from another researcher that gave me some more details, but that is in a gist how this actually operates. And the good news is here is your QR code that I swear is not fishing. It just goes to that URL. I promise I will not hack you. You're not paying me enough for this. And I will upload these slide decks to the um repo for you. So you can go through with your heart's content. If

you want to play with this, you can get an F5 demo um license. They give them up for about a month. You need to use your corporate email to go do the request. They do approve it. They just download the OVA and um activate the LTM and go play with one just to go see how they operate. So you can recreate this to your heart's content and do some more research on what that magical other F5 key does with that questions. >> Yeah. Uh it looks like you know this recovers the password used for the the uh what about like in a PIPS enabled system does >> Oh yeah u sorry u just looking at the

the decryption there looks like you're you're getting the the the sync group uh password so it can get the the configuration. And I'm just wondering if it uh behaves the same in the FIPS enabled system. >> I've never tested it in FIPS to be honest. We don't do FIPS up in Canada. So um it in theory, and this is just me postulating, if they store the key in um in EPROM and they make it so you can't do like an and you can't recover the key, it might not work. But the thing is every F5 needs to synchronize with another pair. So if a FIPS enabled F5 backup node dies or primary node dies and you swap it out, you have to get the

config file moved over somehow and that's the master password is this synchronization key between the two. So in theory, this should work. If you get that master key, one of your texts will eventually have it or yeah, but if someone wants to test on FIPS, let me know. >> Yeah, sounds good. Thank you.

>> It's coming. It's coming. You make him get his exercise. >> I would throw it, but I don't want to buy them a new one. >> Okay, so this problem of synchronous bind passwords isn't unique to F5s, right? You run into this in like SSSD, basically anytime you're a LDAP. A common mitigation we've seen for this is instead of using a bind password, just stick a certificate on the box and then run your LDAP server so that it uses MTLS to authenticate, right? >> Are are you does uh similar problems apply if you're using that mode? Does F5 even support that? like other than a bind password. >> F5 does support storing password or certificates. I don't know if the

configuration allows you to do MTLS to a LDUP system. Um it also depends if the active director let you go do it. But the answer is that you can probably configure it that way. But then the private keys are all stored on the box anyways. So if they're popped, you still have the same problem. >> Right. Right. Right. If your box gets popped, you're dead. Right. Yeah. >> And that's where this whole piece came from was someone's like RF5s should be fine. We don't need to cycle all our passwords. They were popped, but like they're encrypted, so don't worry about the codes. No. The one thing I want you to take away from this, if your box gets

popped, everything that's on there, even if it's encrypted, is compromised. Please cycle.

>> Any other questions? It doesn't even have to be about this. Life, the universe, anything. Hashcat, good sushi restaurants on the strip. >> Sake. Okay. >> So, the - K option was slightly documented someplace. >> Yes. >> Um, what about doing digital forensics to try to dig it out of the binary if it was not documented? >> You know, we didn't attempt to do that because we just knew the command was documented as a like an F5 tech because they have a whole policy on here's how you replace your box. So, I didn't bother. But yeah, you could reverse this thing. All it is is the Linux system under the hood. Thanks.

>> Going. Going. And again, that font was the Atkinson hyperledible font. I swear I love it. I mean, what's everyone thought? Was it fairly readable? >> Cool. Thank you for being my UI testers. Okay, >> awesome. Thank you all. Uh, feel free to hit me up on the socials. In fact, there is my socials again if you want them all. Feel free. I don't bite. I happy I answer questions on Discord. Uh, hashlife universe everything and saki of all things. Okay, before everyone disappears, how many users of Hashcat here? Okay, awesome. How many of you know Hashcat version 7's been just been released? >> Dude, hashcat 7 is amazing. There's so many little cool things that are now in

it. Like I'm very excited. First release in two years. >> Yeah. Yeah. I've got a bit of a summary from Jens from Adam. So, uh, >> over 900,000 lines of code have changed in Hashcat. Uh, this will, by the way, I'll put a QR code up now that you can just scan to get to the Hashcat. uh wiki and see all all all all of this. Um new features that are interesting, a simulation bridge, so you can now integrate external resources into hashcat like FPGAs on the fly. There's a Python bridge. So if you want to write a custom algorithm or you want to support some changes to an algorithm on Hashcat, you can now do

it in Python without having to rewrite uh any or recompile any code. Hash mode auto detection. Okay, for those of us who uh who struggle to identify what it is that we're working with. >> Now, this doesn't work on things like NTLM, MD5, and anything else 32x, but it works on almost everything else. >> Yeah. And then new hash modes, Argon 2, Lux 2 with full GPU acceleration, MetaMask, Microsoft online accounts, GPG, Open SSH, SNMP version 3, and 60 plus more that you're welcome to read about on the wiki. New compute API support. So it's no longer only for Open CL and CUDA. You can now also use it on Apple Metal optimized for the M1 and M2

chips and AMD HIP which is their GPU version of CUDA and of course uh improved performance across all the hash types. So I'll put the QR code up. Um but yeah download hashgate version 7. It's been a part of passwords con since I think inception. There's been talks >> thereabouts. Yeah, but this new version is really amazing with all the things because you also like send out certain parts different parts of a pipeline. It's great for automation of your entire workflow. I'm just so excited. >> Yeah. Cool. So download it, try it out. I'll put the code up now. And finally, once again, thanks very much to Dustin to Elmog for his talk today.

And

I promise it's not going to try and fish you. >> This is not fishing. >> It was Yeah, it was literally created while walking around the room. So, the demo demo makes >> Oh, yeah, it does. Right. It's like it works. It's simple. It's easy to read because I hate doing that black on white [Music] Heat. Heat. [Music] Heat. Heat. [Music] by [Music] Corn [Music] down. [Music] Fire. [Music] D hey. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. Heat. [Music]

[Music]

[Music] Heat. [Music] Heat.

Heat. [Music] Hey Heat. Wow. [Music]

[Music] Yeah. [Music]

Heat. Heat.

Heat. Heat.

[Music] Heat.

[Music]

Hey. Hey. [Music]

Heat. Heat. [Music] Okay, so we'd like to welcome everyone to our next talk at Passwords Con. Uh just by way of reminder, thanking our diamond sponsors Adobe and Aikido and our goal sponsors RunZero and Profit. Then when it comes to the besides photo policy, a reminder that uh the speaker has said you can take pictures of him and or his slides. There's no need to record video. It's being streamed and recorded. But please do not take any photos of attendees or anyone else at the conference without their consent. So just a reminder on that as well. So our next talk is entitled Fishback. How to turn the problem into a solution. I'm going to try and pronounce the name

without destroying it too badly. And that's being going to be presented by Gatia Bjon. So we'd like to invite him now. And yeah, enjoy the talk. [Applause] >> Thank you very much. Um I'm extremely happy to be here today. Uh and I will present you something pretty cool called fishback. How to turn um a threat, the fishing into a detection tool. So let's do this. So first of all, uh my name is Gutier Bjon. Uh so I don't think you'll hear hear a more Frenchy name than that today. Uh and I'm the CEO of Mochen, a cyber security software company. And before that, I've been um the head of cyber security operations for big international companies as well as a

pentester for 10 years. Um, and I'm here today to present you something um that came into my mind after after a big cyber security crisis I had to handle when I was a sock manager um due to a stolen credential. Um, and the results of this new strategy are so impressive that I I felt I had to share it with you guys. So, let's dive in. So, the the stolen credentials problem, let's take a look at the problem first. Um I I really think that password are the gold of the 21st centuries pirates. So why are are they so valuable today? Because one it's very easy to stole them. There is countless way to steal a password and also that

this is and still is the best way to get into a network. So let's see very very quickly how companies have tried to stop this leak madness um of password the past few years. So first they tried to train their employees. Unfortunately most user aren't exactly uh interested in cyber security trainings. After that we tried fishing simulation thinking right let's put them in real situation. They will learn by experience but surprise have you ever met someone telling you yeah we have very very good results at our exercises. Me neither. Um and how the final solution how savior arrived with the dark web monitoring the thing that will save us all. Uh the idea was simple when

a credential gets stolen uh attackers will share it and we will recover it before it's used. Um but I've always seen it like this because uh people in front of us are not dumb. Uh and I think it has been a bit over marketetized through the years. Um my vision of the distribution of liquid is more like this. I really think that some yes eventually ends up on dark web marketplaces but it's a full small fraction. A bigger part is traded quietly under the radar u between attackers in very private groups and the largest portion for me is never shared anywhere is just used in attacks. Those people again are not dumb. They steal a

credential. They just use it. And even if you add MFA on top of this already impressive um stack of tools, stolen credential have remained the number one initial access vector for years. So I really think we have a problem here. Um so I was in this exact situation. I got everything fishing campaigns awareness uh MFA all around and I still got breached by a stolen credential. And so after this big crisis um an idea sparked into my head for a completely new way to handle credential theft. So I'm going to tell you this story. Uh it's a it's a true story that happened to me two years ago. So it all started of course with bad guys. They targeted

just a tiny fraction of the company I was the uh edos for. So 12,000 users and they targeted a dozens of users. Uh it was a very carefully crafted fishing email of course uh and out of 12,000 people four uh sended back their um valid credential just four out of 12,000. So with that in hand uh they followed a very very easy playbook very classic playbook of red teaming or pen testing. They identified everything exposed on the internet and they tried to just connect everywhere with it. Unfortunately for them, I did my homework and MFA was activated everywhere. But unfortunately for me, this time we opened a new subsidiaries in South America a few weeks later and

the network administrator forgot to activate MFA. They discovered it in like 24 hours. They logged in and here was the biggest uh crisis of my life. Um so after the crisis was handled uh I sat down and look at the attackers playbook and I was like okay it's just like me when I do append it's very basic every everybody is doing this what if I had placed a fake VPN gateway among the real ones at the beginning I would have known weeks earlier during their innovation phase that they have stolen uh stolen credential uh and I would have been able to reset the password and that major crisis this would have just been a minor security incident.

Um, and seeing that nobody has documented this approach, I decided to give it a name. I called it fishback. Recovering your credentials the same way they were stolen through fishing, but attackers. Uh, and now I think half of this room have this in mind. Yeah, man. Cool. That's just a honeypot. Uh, nothing new. Uh and yes, exposing omnipot to the internet is nothing new. We've been doing this for years, even decades, but mostly to uh do some threat intelligence to know what attackers are doing out there. But we have never done this with very very carefully crafted fishing defensing fishing pages uh with the goal of um recovering stolen credential. And that's a complete different game. Let me

explain you why. There is two major challenge to overcome if you want to work if you want it to work. So first the illusion has to be perfect inside the corporate network. Attackers have u are in a hurry. They don't have much time to see if your server is a real or a fake one. And even if they start poking around to figure out if it's a fake or not, it's already suspicious. But in on the internet uh there is a lot of people trying to connect uh everywhere every time. So you cannot be sure that it's an attacker or not. And they will have weeks, months, even years if they want to figure out if it's a

fake or not before trying to um to enter their precious stolen password. Uh which means your fake asset has to be extremely convincing. And the second challenge is that and I think you all guessed it, the internet is a very very very very noisy place. So when you put up a login page on the internet, you will have millions of login attempts every single day and you only need the one that is interesting and this is very hard. Okay, so let's see how we do this. First, achieving the perfect fingerprinting. So what do I mean by fingerprinting? For those who don't know, it's a process of identifying the technology behind a system just by looking at small things it expose. So

for example, if you want to fingerprint a Cisco, you go to the web page, you see Cisco, but that doesn't mean it is a Cisco. You need to see the response time, the headers and so on. So this is basically the fingerprinting. And to do this, of course, you could do it manually, but nobody does this. Um, you could use uh very well-known tools like the big guy and map. Everybody knows him. Uh you also have very famous internet scanners like Showdown and Census and even Wapalizer uh for browser extension etc. And the game here is to fool them all to identify your fake page as a real one. So let's take a quick example with with Showdown.

um Shoddan. So for those who don't know, Shoddan is a mass internet scanner that makes basically a complete database of the internet uh not in real time but I think every week um and it fingerprints every single page you find to discover the technology. And how does it work for showdown? It's based on hashes. So it will make hash of the HTTP response, hash of the rendered page and also hash of the row HTML. So you may think okay if you do a fake page you just copy paste uh the pages to match the hashes and it's done. Unfortunately it's not working like that. For example, if we take the foret login page, the hash will

always be different due to um um um uh the e tag sorry in the header which is always always random. So you also have to replicate this randomness if you want to fool into thinking that it's the right technology. And if you just copy paste another one, you will have a duplicate of this thing that should never be duplicate. So it's obvious that it's a honeypot. And the fun part is that it's different for every technology. If you take Outlook web access for example, the ash will always be different. The HTML ash also, but the DOM ash will always be identical. uh and this is due to Outlook uh changing things in the header and and

in the row HTML thing for each single uh platform. So the methodology uh has to be specific to every single tech. Um and I've only shown you here a small tiny piece of one single fingerprinting method on one tool. So imagine the amount of research and finetuning you have to do to to fool all the tool. It's a lot of work. Okay. So now we have tools and scanners that believe that how portal is a real one. But unfortunately we are very far from done. Um building a portal that look like uh real and pass fingerprinting is actually pretty easy. After that, there are dozens of other way to get caught and you will need to

handle things like mobile format, multi- language support. A very very a quick tip to discover if you are on a honeypot or not is just you change your browser's language and if the page stays in English, uh it's basically a honeypot. It's a very very easy way to to find out if you are on a fake page or not. You will also have to handle v HTTP method not just the usual get and post uh replicating a dotic endpoints and for the most cautious attackers even replicate the TCP stack and to do this of course you have only one option which is reverse engineering. So here here is a very very quick methodology quick look at the

methodology we use uh to do this. First the documentation study of course it is a basic u map the existing CV because it often reveal exotic endpoints you wouldn't find otherwise it's extremely important proxy based analysis which is the basic of reverse web reverse engineering uh add some uh directory brute forcing with the for example and the good old click click method uh just click on everything at the end to be sure that you haven't missed anything and just to give you a glimpse of what requires to be done to just uh mimic one single page. I' I've taken the Citrix uh which is a very juicy login page interesting to do an web exposed

honeyot. So just for this login page 194 base endpoint can be accessed and I'm not talking about the application just the login page. Um you have to do this in 12 languages, seven user agents at least and 10 HTTP method and that leads you to at least one more than 162k variation to replicate just for one single page. So this is I I hope you see that how different it is than a standard uh webfacing honeyot. Okay, now we have a trap that almost impossible to detect. But here's the next question. How do we actually get attackers to go for it? Because it's what we want. Uh well, here we have a very very big

advantage because we are playing at home. What is the most uh painful thing for an attacker when he's doing a fishing? It do not have the um the domain and we are playing at home. So we can make the perfect fishing because we have the right domain. Um, so the goal here is to create a domain that really stands out to attackers when they do their enumeration. And what's better than the good old test.comp.com. If there are any pentesters out there, please I I dare you to sell me that you will never check test.comp.com if you find this in your enumeration phase. I I will do it also. It's one of the first you try. Um, you can be a bit more

subtle if you want. You can use homop remote things like that. But be sure to study your external parameter because the domain needs to blends perfectly into the environment uh or it will be too obvious. And finally, how do we deal with the massive massive noise you will get? So let's see what we get into our honeypots. First uh we will have an industrial amount of login attempts coming from the bots. Of course, absolutely zero value, no interest at all. Number two, we have the opportunist. So, this guy found a combo list on an obscure forum. Uh, and he's very happy to spread to do some password spraying all around. So, most of these these attempts will be bad ones, but I

don't know why they have sometimes valid credentials. So, you cannot fully ignore them. And uh finally the real attackers they uh make very very very little noise but they have the attempt the attempt they want we want sorry so sorry it will not be rocket science or AI or things like this just apply for example first the password policy if someone is trying 10 character password and your password polic is 12 characters long yes it's fake or it's old but it's not interesting. After that you can apply your some um regular expression to catch your first name.ast name for example or uh if you are first name do name or things like that and even just with those first two

you eliminate 95% of false positives. After that you can check for u already leaked password if you are doing dark web monitoring and if the brute if it's a part of a brute force or a password sparing with no interest and will all that you get a qualified alert but that doesn't means that it's a right password you came from millions of attempt to dozens hundreds um and now you have the final step to do which is the automation so you have to connect to your active directory octa ID whatever you have to be sure that the password is the right one before resetting it. But if I summarize, if you implement this correctly, you will only

have alerts when someone is trying to connect on a fake portal that nobody's ever heard about with a valid credential. So that is a critical alert. Okay. And now the question is, do they actually fall for it? Um, honestly, when I launched this strategy, I I I knew it has had a huge potential. Uh, I've been a pentester for 10 years, and I was like, okay, if I ever go uh in front of this, this would be a nightmare because how do you know if it's the right domain, if the pass the page is wellcrafted? Um, you you cannot know it's it's a fake one. Um, but I had no idea if it would work. And this is not

something you can test on a lab. If you go on a lab with a domain with no risk at all, no no exposure, um there is no way you can see if the strategy is working. Um so we have deployed this strategy over the past year and a half in over uh 20 large international companies and I can I can share some numbers with you. Um so around 50 portals for 20 companies. Um we have processed 2.3 billion login attempts and out of those 2.3 billion attempts. Uh we've identified 257 valid credential without any dark web uh exposure. That's huge. That's way far more than I ever expected. uh I thought yeah maybe we will get one or two uh 10 uh at maximum

but 257 with zero dark web presence on only 20 companies so it's it's big big companies with hundred and hundred of users but still uh it's huge and to put this in perspective those 257 valuable items represent 0.1% of all login attempts so that proves that without a flawless execution of the automation and the filtering, this strategy uh is useless completely. Um and as a conclusion, I would say that fishback is a strategy that looks extremely simple on paper. It's just a honeybot, but you have um to execute it with extreme attention to detail if you want to reveal its full power. Um, and as a tech guy myself, I'm completely amazed with the results. Uh, because I

knew in my heart that dark web monitoring wasn't exhaustive at all. Uh, but seeing the proof is extremely extremely exciting. Thank you very much. [Applause] We are out of time for questions, but I'm sure you'll hang around a bit. Uh just uh in between the talks, you're welcome to to ask any questions that you have. And coming up next at uh 11:00 a.m. will be lessons from Black Swan Events and Building Antifragile Cyber Security Systems by Dave Lewis. So hang around for that one. That's going to be good as well.

[Music] Heat. Heat. [Music] Do you remember?

[Music] Heat. Heat. [Music] Heat. Heat. [Music] Fire. [Music] Down. [Music] Heat. Heat. [Music] Down. [Music] Hey. [Music]

[Music] Heat. [Music] Heat. [Music] Heat. Heat. N. [Music] Heat. Heat. [Music]

Heat. Heat.

Heat. [Music] Heat. [Music] [Applause] [Music] Heat. Heat.

Heat. Heat. [Music] Heat.

[Music] Heat.

Heat. Heat. N. [Music] Heat. Heat. [Music] Heat. Heat.

[Music]

[Music] Okay, we'd like to welcome everyone to our next uh presentation. I'm I'm Dimmitri aka Rura Pente. I'm running Passwords Con for PUR this year and we'd like to welcome everybody. Uh talks have been very good so far. So, we sure you're going to enjoy this one as well. Just by way of reminder, we'd like to thank our diamond sponsors, Adobe and Iikido, gold sponsors, RunZero and Profit. A reminder about uh taking photos. So, you can take photos of the speaker and his slides. He's okay with that. But the besides uh policy against photography is that you cannot take photos or pictures of any of your fellow attendees without their consent. So, just keep that in mind, especially if

you want to take a slightly wider wider shot. that applies to the whole conference as well. Awesome. So, we're now going to enjoy lessons from Black Swan events and building anti-fragile cyber security systems from somebody that's uh been in the field for quite long, very experienced. I've heard many of his talks and I'm sure you're going to enjoy this one just as much as all the others. So, let's hand over to Dave Lewis. >> Thank you very much. That was the nicest way to be called old I've ever heard. I appreciate that. >> Well, thank you everyone for being here. And this is really an interesting moment for me because I realized I've actually never spoken at Bides. Uh oh, no, that's

not true. I spoke at the first Bides Las Vegas. That is actually that is true. And this is my second time. I just remembered that as I started talking, but it's one of those amazing things is like to see this event grow into what it has become is really cool and that you you have taken the time to be here is I do appreciate it. So, I've been doing security in one form or another for far too long. Uh I've been doing this for 31 years now and along the way I've done all sorts of different things and during the pandemic I got into, you know, whiskey distillery ownership as well as a soccer club in Vancouver, Canada. And

uh it's kind of interesting along the way. So, I do work at One Password. is not a sales pitch by any stretch of the imagination, but I absolutely love working there. Great culture. I also do supporting for sighteline security, uh, BIOS as well as come on slides. There you go. Gnostic AI and a few other companies as well. So, it really keeps me hopping to say the least. Now, one password, the one thing, the only reason I'm putting this up here is because people think we're just a BTOC company. So, we spent 19 years doing B TOC. So, it's an understandable thing. In the last year, we've really gotten to the enterprise space and that is as far as

I'm going to go there. If you ever want to talk about that sort of thing, feel free to look me up. Now, I am a hacker in Canada. That means a little bit of a different thing. We tend to approach things a little bit differently. And yes, I am Canadian. So, this is one of those things which is All right, we got another one. All right. They're going to get you. Um, it's one of those amazing things like I did the keynote at Biz Knoxville this year and it was really amazing. I came out on stage and I said, "Just to be clear, we love all you. We just don't like one person in particular." Um, and that was very

wellreceived. So that's just it is like as part of a community, we all are from different walks of life and it's amazing to be a able to be part of this and I do appreciate it. Now I do feel like this particular character far too often after having done this for 31 years and realizing that this keeps happening and when I say this I mean all the security issues that pop up. What I do like to talk about is blast black swans as a cyber security event. Now this is derived from a book by Nasm Taleb fantastic book and it was applied to markets and market conditions and things like that. But if you take these lessons

learned and apply them against cyber security it is always a incident that has massive impact that in hindsight was easily solved and sound like something that we've heard far too many times and this is just it. We have to get better at shoring up our defenses. Shocking statement I know but this is one of those really amazing things that like we keep having these same conversations now black swan events like I said there's a level of unpredictability you know oh we never could have imagined that that particular company could have been breached massive impact millions of records in these days billions of records being exposed and always the rationalization it's like oh if they had

only patched how many times we heard that and it's never that easy not patch you was a great example and then we look at other I'm doing a little bit of a sprint here because I didn't realize I only had 20 minutes so that was on me. So we have all of these different types of breaches we've heard about and this is not to throw mud at any of these. This is just to really illustrate this could happen to any one of us and you know I've actually gone through a data breach myself and that was a very unpleasant experience in the company I was at. I went in in the morning, there was a

stack of notes there saying, you know, from my admins saying this public Wall Street Journal called, this journal called, CBC called, and like, oh, this is going to be a bad day. And that's just it. It's like that was how we measure things and now we have to deal with this on a consistent basis. But was the incident that happened a black swan event, was it really unpredictable? Was this something that we could have addressed? A lot of times, yes. How many people remember the Marai botnet? Show hands. Yeah, there's an interactive portion. Okay, that's better than I was hoping for. So, that's good. So, the really amazing thing is the Ryan botnet was using default credentials on

62 different devices that were attached to the internet that made a massive botnet. And then I heard, oh yeah, well Dave, that's an old story. Well, this is really interesting. So, here's an article about the largest DDoS attack to date by the Mariah botnet. And oh, wait, what's that date there? Let me just blow that up. Right there. That was this year. Mariah hasn't gone away. it has gotten bigger and these are the kind of things that in hindsight could have been fixed programmatically. There's no reason to have a device that when it attaches to the internet it doesn't change the default credentials as soon as you log in. Having default credentials hardcoded in devices and you

know my former employer vendor name vendor name as username and password that is inexcusable at this point in time. There we go. And this is how I usually approach it when people ask about cyber security. I say this is generally how I approach things overall. And passwords, they have limited utility. This is a control. This is not a security control. It's like your house key. Yes, you can lock your door. You can protect your stuff. But when you leave for the day, if you lose your key somewhere along the way, somebody finds them and they have picture of you and your kids. Well, it's not that difficult to figure it out. You know, Google lens like, "Oh, this is

this person. Oh, okay. There you go." Get into the house. House doesn't know any better. And large groups uh of uh I'll try that in English. Large groups of criminals out there are making bank on this. Like this particular Vietnamese group here. Uh whoops back. $71 million can. The crazy thing is this group of hackers that was making all this money based on stolen credentials. Four people. >> One group out of many. And this has been going on for years. When I used to work at Aamite back when the world was flat, we used to follow these groups all the time. There are so many of them and they're still around today and bad things keep happening. Like back

in the day when I was working at a power company, we had this really interesting thing where we found an ARP storm. We couldn't figure out where it was coming from. We traveled all across, you know, all the different systems saying, "Is it this? Is it this? Is it this?" None of it made sense. So finally, I just broke down and I did, you know, AAMS Razer. I grabbed a tile lifter, walked out into the data center and started lifting tiles because I'm like, "I'm out. I'm out of options." The third tile I picked up, there was a Cisco 1750 blinking back at me that nobody knew about. It was under the floor. So that company used to be part of a

larger company that had been split into five smaller companies. It was a direct connect to another company that was ostensibly our competitor at that point. That was inexcusable. The best part was they didn't know about it either because it was under the floor in their data center as well. We never did figure out who put this in, but I guarantee you it was somebody I was working with. So, we really do tend to follow our own rules and we have to make sure that we are looking at better ways to improve things overall because we can't make the same mistakes over and over again and hope for a better adventure. And having that mentality is

something we have to address because when we're dealing with, you know, finance, HR, all the rest of the organization, they're very good at what they're good at. But expecting them to be well-versed in security is not going to work unless we are working with them. Because if we're not getting the message across and they make a mistake, we can't vilify the user. It's not going to help. We have to make sure that we're doing a better job because we can't be that flaming sword of justice where the answer is always no because data breaches are going to continue to happen. This is one of my favorite sites. Anybody familiar with information? Yeah, informationis.net. All right. If you for those that don't,

look it up. It's amazing. They just do all these really uh great data visualizations for data sets. One of them is data breaches. So this is a relatively recent one where you see orders of records of 1.3 billion records, half a a billion records there, half a billion there. The stakes have changed. We keep talking about data breaches and yet we keep having the same problem, but now the breaches are getting bigger. So we have to look at better ways to approach things. We have our ways that we triage events and deal with things. But this is something that was brought to my attention by Rich Mogul. If you're familiar with his work, he does great work with Cloud Slaw and

various things like that. This was something from God, I forgetting. Well, he does physical incident response. So, if there's a hurricane or something like that, he would go through and address these. And part of this is how they would approach matters. And here is another slide. Come on. Where it goes. Oh, yes. the disaster response smart book from the incident command system. So it's not ICS and control systems, but you know, I can see where that collision can happen. And this is how they go through and they triage events. These events, yes, they're going to have massive impact. They can be unpredictable, but they do have a playbook on how they can address it and

then fundamentally reduce the risk to those affected. This is the kind of thing that we have to change our thinking as security practitioners because these events keep happening. the orders of magnitude of breaches is so large now that it's really unconscionable and flip it on its head and look at ransomware attacks back in 2017 they were all the attackers were going after the large companies like you know Bank of China NHS so on and so forth because this was the big thing at the time and then we saw it drop off in 2018 they weren't going after the size was based on the size of the company but as we transition over here to 2010 all of a

sudden the ransomware operators are back in force. Can anybody tell me what happened in 2020? >> Bingo. COVID 19. All of a sudden, the attackers were sending emails saying, "If you don't click this link, you're going to lose your healthcare coverage, all the rest of it." Nobody knew what was going on. I didn't know what was going on. Anytime a package came to our house, my wife and I would get on full hazmat gear and do sanitize the whole thing because we had no idea how it was coming in the house. This is why ransomware operators started being successful. And as they progress across to 2023, which was the most recent data, the bubbles are getting smaller because

the attackers are going after the smaller companies because a lot of these small shops have contracts with larger companies. So the attackers are then pivoting through there. So we have to make sure that we're doing a better job of approaching these things because we have to learn lessons from these data breaches and we have to look at what went wrong. And this is not a case of pointing fingers. We have to say okay we have to have frank and open discussions. How many times we talked about better communication. If we look at the financial systems we look at juristprudence we look at medical profession they're really good at sharing lessons learned. We have a lot

of work to do in our field. Capital one. This was a shadow IT moment where misconfigured W led to 100 million credit cards exposed. Uber 57 million users exposed for a GitHub repository that got breached. Come on. Oh, yeah. Dow Jones. Amazon S3 bucket. This is my favorite one to pick on because it's so very simple. Anybody can set up an S3 bucket with a credit card and a web browser and off they go. Unfortunately, they make these things public and that it's a data repository. You can put whatever you want in it, but they are discoverable and most people don't understand that even though when you log in in the console in bold print says do

not make this public unless you know what you're doing. Paraphrasing of course, but that was essentially the message. Now, I used to work at a high-tech manufacturer. Within the first couple weeks on the job, they said, "Okay, let's go through and look at all of the accounts that had super user status that belong to users that no longer with the company." All right, we did that and we found there were 10 user accounts that had root access that the users were no longer at the company anymore. And I tell this story over and over again, so if you've heard it before, don't give it away. One of these users, their account had been used in

the last two years, but they were no longer at the company. Can anybody guess what the wrinkle was with this particular account? >> It was cooked into a system where it was running as a human instead of a service account. >> That's a good answer. I hadn't heard that one before. But the actual reason was this person had actually been dead for five years. >> So, we had a ghost in the system. What happened was it was somebody that was using it on a post-it note. Cliche, I know, but they were using on a post-it note to go in and check a crown job. So, basically close to what you were hitting on there. But this is the kind of thing

that is absolutely maddening because this type of thing happens far too often and we're like, "Oh, that's okay. We're in the cloud now." Same problems persist. It keeps happening. This is normally where I'd have my coffee break, but I just realized I have no idea what I did with my cup of coffee. All right, moving on. We have to look at things like the psychology of passwords. We always like to pick on people like, "Oh, your password was querty." Okay, well, why is that? We didn't teach them well. But people try to do things that are going to be as easy for them to understand. And we have to make sure that we're looking at ways to give them

better ways to approach things. How are they going to do better on their security approach? How can they pick a better password? If you've never seen this XKCD comic, go look it up. I love these love this strip in in all of its glory. But there are better ways to approach that. We have better technologies that are out there. All sorts of different ways that we can approach better password security. Multiffactor authentication, biometrics, phto, pass keys, all of that will help reduce the risk. And fundamentally, that's what we're trying to do. We're trying to reduce the risk overall. Are we going to solve 100% of the problems? Hell no. That is not part of the deal. I

wish it was, but it's just not, you know, realistic. We have to look at proactive measures. We have to feel figure out how we're going to create resiliency. You have to have systems that can take a hit. When I was at my previous company um that I mentioned earlier, one of the things was we did not believe in nine uh what was it 59 that was not part of the equation. It was 100% uptime and we designed our systems exactly like that. We had one nation state actor that took a poke at us. They told us they were going to because they were testing our systems. Thankfully, we stayed up 100% of the time, but that's just it. These days,

the technolog is available for you to have resilient systems that can take a punch. And when you're looking at it from the perspective of a black swan event, not only taking a punch, but being able to learn from it and do better, you want to have systems that can take that hit and be antifragile. And this is really about the concept of exactly what I was just talking about of having a system that can take a punch. So I realize I'm getting ahead of myself in the slides because I did this talk in Athens, Greece a couple weeks back and the slide projector didn't work. So I had to ad liib the whole thing and I'm

actually kind of happy I'm on point. So shadow it is another piece of the puzzle that keeps coming around to bite us especially when it comes to unmanaged devices. And the really fun thing was is I had this or had a very similar talk to this in Toronto Canada but just over a year ago I said all right everybody in the room who here has um controls in place from a technological perspective for shadow IT. The whole room put their hands up. There we go. How many people have policies in place to deal with shadow IT? The whole room put their hands up. I was like, great. I was like, okay, dramatic pause turn. How many

people in here have shadow it? Everybody put their hand up. It it's just a thing. And that's just it. When I'm talking to customers and saying, look, how are you managing this? They often say, oh, it's not a problem. We have a policy, but it yet it exists. It's sort of like Schroinger's IT security problem. So you have to have good preparation because in order to protect your organization, you have to do your work to look at where the problems are uh within your organization and be able to address them in an expeditious fashion. And when you're dealing with data breaches, for example, you have to have a good incident response plan. And when I say a good incident response plan,

practice it. I worked for a power company where we had an incident response plan and I found out we hadn't touched it in 10 years. And I looked at it, it was completely out of date. As a tangent to that, we went through and looked at all the policies that were available and there was one that made no sense what whatsoever. It was a particular certification we had to have and I couldn't find this for lover money. Searched online, nothing. Finally, the person who wrote it was still with the company and had been there for 20 years. And this person admitted to me that what they had done was they had found a certification online that did an a search and replace

for cyber security. And so that was part of our policy set that senior management has signed off on this particular set of policy. Well, this particular policy document was originally a certification for swimming. Unfortunately, this happens a little more often than I thought because the first time I gave a talk where I brought this up, I had two people come up to me afterwards and they had similar type stories. It wasn't swimming, but it was very, very similar where somebody had done a search and replace just to tick the box and say, "Yeah, we're all secure now." Now, shadow it, it's usually done out of a case of speed and convenience. It's never out of malice. People are trying

to get their projects done to satisfy, you know, the aspirations of the business. And other times, it's, you know, perceived inadequacy. Yeah, pretty neat. Perceived inadequacies with the solutions that are available. One company I worked at, we had seven different logging and monitoring solutions because people didn't think that the logging monitoring solution that was in place could help them with their project. So they added in for every project that was being delivered, they had yet another logging monitoring solution. There was no sunset provision for any of these. So they limped on in perpetuity. The other piece too is we're always told to innovate and experiment, but usually that happens in production. And I wish it didn't, but you need to

have an environment in order to address these things because you have a risk to data security. You have to look at the risk of data loss because I'm sure everybody's using sanitized data and there's shadow IT. I'll stop risk and compliance. There are real fines that you have to be aware of. This is a problem that can have material impact for an organization if that data gets leaked. Risk the bottom line, that financial impact. The beige desktop's one of my favorite stories. It'll be really quick on this. This was How many people have ever seen a beige desktop running a mission critical app on? I'll stop there. I got enough. This is maddening because this happens

so often and people don't know how to get it off because the code was written by a summer student, not properly documented, it works and suddenly it has become priority within the organization. We have to get better at addressing these sort of things. And if you have a summer student writing code for you, get them to document stuff so that you can deal with it because otherwise bad things are going to happen. This one here was another system that was causing problem in the network and we had all of the contact sheets for all the different uh servers set up. This one had no name associated with it. So after trying exhaustively to go through the entire

company of how who owns this, how it was being run, all the rest of it, no answer. Finally, I did what I don't recommend people do, but I did it anyway. I pulled the Ethernet cable and I tied a note to it and I walked away. >> Scream test. >> Exactly. The scream test. Sure enough, in came Nick. Love this guy. Came in, beat red. Absolutely angry as all get out. He's like, "This is mission critical system." I'm like, "Come with me." We walk over to the rack and I said, "This yours." And he goes, "Why is it unplugged?" Said, "We had a problem with it. This notes for you." So I took it off and it was sealed and I had

signed it across there. So he looked at it, he goes, "Huh?" He opens it up, reads the letter, goes, "Hm, thank you for your time." And he left. It had been nine months since I wrote that note. So that system got taken offline really quickly. But that's just it. It's like a lot of times it's like these missionritical systems aren't necessarily mission critical. So we have all sorts of different case studies. I'll skip through that on the for the sake of time. But when we're looking at the future of cyber security, spit on the floor if you must, but zero trust architecture is a really good way to go forward. This is not a product anybody's

trying to sell you. If somebody says it's a zero trust anything, they're lying. Zero trust is a strategy. You want to be reducing risk in your organization. Continuous authentication, verification, micro segmentation, extended access management, and the rise of cyber insurance as a safety net. The problem here is too many companies are relying on this as their get out of jail free card. This will help you cover off the investigation dealing with, you know, critical messaging to stakeholders, but it will not make you whole again. So, if you're relying on this as your get out of jail free card, you're going to have a bad day. There is the government uh in Hamilton, Ontario recently went through a data breach

where they have spent about $18.3 million uh with people doing an investigation restoring the whole. insurance company turned down their claim because they had no multiffactor authentication which was in paragraph one of their agreement. Let's skip by that. If you are looking at problems within your environment, we talked about it earlier where you have an environment where you know something is going to be it couldn't happen here. It's unpredictable. If you have 10 people looking at the issue, the job of the 10th person is to say yeah the bad thing can happen and here's why. Because if you have everybody agreeing, you become a Greek chorus. You're just going through the motions. You want to have

somebody that's on staff that can literally say, "This is the alternative theory that we have to look at. We've checked all the boxes." So, the road to hell is paved with the good intentions and we have to make sure that as we move into artificial intelligence, especially from an agentic AI perspective, we are approaching this in a right way. AI is not here to replace people in their jobs. I've seen companies make this mistake. CLA, to their credit, fell on their sword. They let go of 700 people and they said, "This was a mistake." AI can help 1x staff and we want to make sure that we're approaching it from that perspective. And that brings a whole

host of security issues with it as well. And I am at time so I'm going to cut myself off there. Emma, yep, I got a full stop. All right. Thank you very much for your time. Um, the entirety of the slides will be available if you want to email me. I'll just do put that up real quick because I have a lot of stuff here. >> I just put a QR code. >> A QR code? Yeah. You get out. Oh, yes. I have a podcast if anybody's interested. The Chasing Interview Podcast. There you go. There's a QR code. And I guarantee you there is no uh never going to get you up there. All right. Camera's down. Okay. And yeah,

feel free to email me gatka@1epass.com. I can give you a set set of the slides or we can chat or whatever. And I really appreciate everyone for your time today and thank you so much for being here. >> Thanks very much Dave. Thanks everyone as well. And yeah, enjoy the lunchtime break at 2 p.m. will be the next passwords can't talk. You don't want to miss that one either. It's going to be very good. So check the schedule and we'll see you back here at 2. [Music] Yahoo! [Music] [Music] Baby, [Music] bounce. [Music] Black. [Music] Doo. [Music] Down. [Music]

[Music] Heat. Heat. [Music]

Heat. [Music] Heat.

[Music]

Heat. Heat. Heat. [Music] Heat.

Heat. Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. [Music]

Hey Heat. Heat. [Music] Heat. [Music]

Heat. Heat. [Music]

[Music] Ooh. [Music] Ooh. Hey. [Music] Heat. Heat. [Music] Wow. [Music]

[Music] Heat. [Music] Heat. [Music] Heat.

Heat. [Music] Heat. [Music]

Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat. Heat. [Music] Heat. Heat. [Music] Heat.

Heat. Heat. N. [Music] Heat. Heat. N.

Heat. Heat.

[Music] Yeah, [Music]

down. [Music] Hey, hey hey. [Music] Yeah, [Music] down down. [Music] Down down down.

[Music] Heat. Heat. [Music] [Music] Heat. Heat. N. [Music] Hey. Hey. Hey.

[Music]

Down. [Music] Down. [Music]

[Music]

Heat.

[Music] Heat. [Music] Heat. Hey, Heat.

[Music] Heat. Heat. [Music] Heat.

[Music] Heat.

Heat. Heat. Heat. [Music] [Applause] Heat. Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. [Music] Heat.

[Music] Heat. Heat. [Music] Heat

up

[Music] here. [Music] Hey. [Music] Heat. [Music] Heat. [Music] Wow.

[Music] Heat. [Music] Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. [Music] Hey, Heat. Heat. Heat. N.

Heat. Heat. N.

[Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. N. [Music] Heat.

Heat.

Yeah, [Music]

[Music]

yeah yeah yeah. [Music] Wow, [Music] hey, [Music] hey hey hey hey hey hey hey hey hey hey hey. Yeah, [Music] down down. [Music] Down

down down down.

[Music] Heat. Heat. [Music] Fire. [Music] Hey. Hey.

[Music]

Down. [Music] Hey. [Music] Heat. Heat.

[Music] Heat. Heat. Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat.

Heat. [Music] Hey. Hey. Hey. [Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music]

[Music]

[Music] Heat. [Music] Heat. [Music] Wow.

[Music] [Music] Heat. [Music] Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. [Music] Heat.

Heat. [Music] Heat. [Music]

Heat. Heat.

[Music] Heat. Heat. N. [Music] Heat. Heat.

Heat. Heat.

[Music] Yeah, [Music] down. [Music] Hey, hey hey. [Music] Yeah, [Music] down down.

down.

[Music] Hey hey hey. [Music] Heat. Heat. [Music] [Music] Boo. [Music] Hey. Hey. [Music]

Down. [Music] Down. [Music]

[Music] Heat.

[Music]

Heat. [Music] Heat. Heat.

[Music]

Heat. Heat. Heat. [Music] Heat. [Applause] Heat. Heat. [Music] Heat. Heat. N. [Music] Heat. Heat. Heat.

[Music] Heat. [Music] Heat.

Heat. [Music] Heat. [Music] Heat [Music]

up

[Music] here. [Music]

[Music] Hey. [Music] Heat. Heat. [Music] Hey,

[Music] hey hey. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat [Music] up Heat.

Heat.

Heat. Heat.

[Music]

Heat. Heat.

[Music]

Heat. Heat. [Music] Heat. Heat. N. [Music] Yeah, [Music]

[Music]

down. [Music] Hey, hey hey. [Music] Yeah, [Music] down. [Music] Yeah,

[Music] Hey, [Music] hey, hey. Heat. Heat. [Music] [Music] down. [Music] Heat. [Music] Hey. [Music] Hey. Hey.

[Music] Heat. Heat. [Music] Heat. Heat.

[Music]

Heat. [Music] Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. N. [Music] Heat. Heat.

Heat. Heat. [Music]

Heat. [Music] Hey. Hey. Hey. Heat. Heat. [Music] Heat. Heat.

[Music]

[Music] Heat. [Music] Hey Heat. [Music] Heat. Heat. [Music]

Wow. [Music] Heat. [Music]

Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat. Heat. Heat.

[Music] Heat. Heat. N. [Music] Heat.

Heat.

Yeah, [Music]

[Music] heat. [Music] Yeah, [Music] hey [ __ ] Yeah, [Music] down down. [Music] Down

down down down down down.

[Music] Bye-bye. [Music] [Music] Black. [Music] Hey. Hey. [Music] Down. [Music] Hey. [Music]

[Music] Heat. Heat. [Music] Heat. Heat.

Heat. Heat. [Music]

Heat. Heat.

Heat. Heat. [Music] [Applause] [Music] Heat. Heat.

[Music] Heat. Hey, heat. Hey, heat. [Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

Heat. Heat. Heat. [Music]

[Music] 2. Hey, [Music] hey hey. [Music] Heat. Heat. [Music]

Wow. [Music] Heat. [Music] Heat. [Music] Heat. N.

Heat. Heat. [Music] Heat. Heat.

[Music] Heat.

[Music]

Heat.

Heat. Heat.

[Music] Heat. [Music] Heat.

Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat.

Yeah, [Music]

[Music] heat. [Music] Yeah. [Music] Sh. Yeah, [Music] down down. [Music] Down

[Music] Hey, [Music] hey, hey. Heat. Heat. [Music] Heat. Heat. [Music] [Music] down. [Music] Boo. [Music]

Black. [Music] Hey. Hey. [Music] Hey hey hey. [Music]

[Music] Heat. Heat.

[Music]

Heat. [Music] Heat.

[Music]

Heat. Heat. Heat. [Music] Heat.

Heat. Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. N. [Music] Heat. Heat. [Music] Heat.

[Music] Heat. [Music]

[Music] Heat. Heat. [Music] Heat. Heat. [Music]

Wow. [Music] Heat. [Music] Heat. [Music] Heat.

Heat. Heat. [Music] Heat.

Heat.

Heat. Heat.

[Music] Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. N. [Music] Heat. Heat. N.

Heat. Heat.

[Music] Yeah, [Music]

down. [Music] Hey, hey hey. [Music]

down. [Music] Down. Down down.

[Music] Heat. Hey, Heat. [Music] Daddy [Music] [Music] B. [Music]

[Music] Heat.

[Music] Hey, heat. Hey, heat. [Music] Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat. Heat. Heat. Heat. [Music] Heat. Heat.

Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat.

[Music]

[Music]

[Music] Heat. Heat. [Music]

Wow. [Music] Heat. [Music] Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat [Music] up here. Heat. Heat. N.

Heat. Heat. N.

[Music] Heat. Heat. Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. N. [Music] Yeah, [Music]

[Music]

down. [Music] Hey, hey hey. [Music] Yeah, [Music] down.

Down

[Music] Hey, [Music] hey, hey. Heat. Heat. [Music] [Music] Heat. Heat. N. [Music] Fire.

Home. [Music]

down. [Music]

Heat. Heat. [Music] Heat. [Music] Heat.

Heat. [Music]

Heat.

[Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat.

[Music] Heat. [Music] Hey Heat.

[Music] Heat. Heat. [Music] Heat. Heat.

Heat. Heat.

[Music]

[Music]

[Music] Heat. [Music] Heat. [Music]

Wow. [Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat.

[Music] Heat. [Music]

Heat. Heat.

Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. [Music]

Heat. Heat. [Music] Heat.

Heat.

Yeah, [Music]

[Music]

yeah yeah yeah. [Music] Hey hey hey hey hey hey hey hey hey hey hey. Yeah, [Music] down down. [Music] Down

down down down down down.

[Music] Hey, [Music] I'm [Music] Goodbye. [Music] Baby, [Music] daddy. [Music] Fire. [Music] Down. [Music]

[Music]

Heat. [Music] Heat. [Music] Heat. Hey. Hey. Hey. Heat. [Music] Heat. [Music]

Heat.

[Music] Hey Heat.

Heat. Heat.

[Music] Heat. Heat.

[Music]

[Music]

[Music] Okay, welcome everyone to our next track at Passwords Con. I am Dimmitri aka Rura Pente. I'm running Passwords Con this year. So, it's great to see such a full room. It's really nice. Uh I'm sure you guys are going to going to enjoy it. Uh just a quick uh some quick thank yous to our diamond sponsors, Adobe and Aikido, and our gold sponsors uh Drop Zone AI and Profit. And then a quick comment about uh cell phones and cameras. Please put them on silent so that uh they don't go off and we don't hear all the uh the interesting ringtones that you may have. And then when it comes to taking pictures, just a

reminder, the speaker said you can take pictures of him and or his content. That's right. Yeah. But uh don't take pictures of anyone else in the room without their consent or anywhere else in the on the venue as in the venue as well, I should say. Cool. So taking down the grid, I think that's why it's so full here. It's very interesting top topic. It's interesting for me too because I'm from South Africa and we don't have to try very hard. It brings itself down most of the time. But uh I'm going to pay for that comment, but it's okay. Um but yeah, it's a very interesting topic. Passwords con um as you can see spans quite a wide area

because of the fact that it covers so many different topics. So I'm looking forward to hearing this. I'm sure all of you are as well. So let's hand over to John Andre Bjok. >> Thank you very much. There are some passwords in the talk. So uh I think we'll we're under the password umbrella. Uh my name is John Andre Bjork. Yandre Bjork in Norwegian. Hey. Uh I'm Norwegian. I work for a Norwegian company called Net Security as a principal penetration tester. I'm originally electronics engineer with a specialization in telecommunication and wireless systems. It's much more fun to break stuff than building stuff. Therefore, I do a pentesting. I've been doing pentesting for 17 years. Uh I picked my first lock when

I was 10 years and I got got hooked into the physical security area already. Then this entire talk is a war story. It's one uh red team assignment that we did. Um the assignment was, as I said, a red team exercise. Everything was allowed except hurting people and damaged property. The goal was to get into the EMP secure server room for a large uh power company, which controls a large part of the power grid for a for a country. Uh when inside the EMP secure room, we should place a fake uh a dummy bomb just to uh simulate that we could place something scary inside that room. Um because that room controlled the OT all the OT that control the bobber grid.

So if a bomb would go off there, it would take down the grid. Um when we start when we do a test like this we first start with uh recon of course doing oint and some physical recon we use Google maps link it in homepages everything we can find online for the physical uh recon we're driving around the property walking around the property uh using cameras with uh high zoom lenses telescopes binoculars and so on to get as much information as possible um on the uh target. There are some movies hidden in the in the presentation. So if uh someone recognizes the movie, you can uh shout out. Which movie is this? >> Yep. Correct.

Uh before we got into the physical part of this uh this test, we did a fishing campaign to get some domain credentials in case we got access to some uh computer inside the facility. Uh we wanted to find out what kind of access control system is used, which technology is it my classic, is it uh HID, is it EM cards or whatever. And we also wanted to make some ID cards, visually correct ID cards that we could use to blend in in the environment cards like this. Very successful to have a mix of different uh different ID cards when you're on a red team exercise like you. This is a mix of Norwegian companies. You have cleaning companies,

you have uh computer companies, elevator companies, ventilation and so on and some guard uh companies. So the first step in this um in this test in this uh exercise was to get an access card with a pin from recon. We knew that they had a Stanley access control system that we could see from Google Street View. We found the exact reader and we found on Google image s search that this reader supports a lot of technologies. It supports uh 125 kHz cards. It supports my classic, my desfire and so on. And we were hoping that they used one of these weaker technologies like 125 kHz or my classic. Uh but to find out the exact technology

that they they were using, we had to get very close to the um to the reader using a flipper zero. And we found out that this is a myer classic and using uh the flipper you are able to extract the data that can be used to calculate the encryption keys and you also get the uh sector and the key that is used and using the flipper app you're able to de decode the um encryption keys. So we have then the microclassic sector the area on the card the location on the card where the interesting data is uh stored and we have the encryption key having this it is possible to uh to skim cards to clone cards.

Now how do you do that? There's two ways of getting a copy of a card. Either you can get close to people but we don't want to get close to people. It's Yeah. No. Um or you can use a weaponized reader or some skimming equipment. A weaponized reader is a lookalike reader who is built to skim cards instead of just um opening the doors. But the weaponized readers that it's possible to buy are really expensive. And we found out this when we were starting on the on the um assignment. So we didn't have time to order the the um the reader and we didn't want to use so much money on it. So we don't have

money. We don't have time. What do we do? We improvise. We take whatever we have build something and yeah hope that we'll building something that is able to skim the cards. So we had a reader, we had a Prox Mark, we had a Raspberry Pi in our briefcase, we had a power bank. Uh we needed a Oops, that's a Yeah. Uh we needed a case to put everything in it. We wanted to control this from remote. We didn't want to stand next to the uh reader and connect to the Wi-Fi on the Raspberry Pi enclosed in a case. We wanted to be able to connect to it remotely. So, we used a 4G uh modem

connected to the Raspberry Pi. We needed to have some cables to connect everything. And of course, we needed some tape to tape it up on the uh on the wall. um the to to put every all this equipment into one case. Uh it's not possible to get a very discrete reader. So we use this. It was the smallest case that we could fit everything in because we needed a quite a big power bank because we didn't we wanted to mount this in the middle of the night so no one was around and hopefully when people are getting to work uh they uh wouldn't see the small box that we placed under the the reader. So we put everything into the uh this

exact box. We wrote uh contact information on the back side. This is a security test. the name of the company, my phone number and so on. We placed it under the reader. >> Very discreet. >> How did you place it there? With magnets or what? >> Tape. Double-sided tape. >> Nice. >> Yeah, it was nice in until we should when we were taking off the wall because the tape was a bit too strong. So, a little bit of the painting was removed. >> Why not post a note that just says, you know, don't remove this maintenance test or something. >> Yeah, I could have, but then people would read read that and what's what's this? Maybe contact the janitor or

something. But the funny thing is that no one noticed. Uh, and there were also some people who tried to push it thinking it was a open the door button or something. So we got an idea after after this that we have to use one of these and build a weaponized button. Put some uh a reader inside this and put it next to the uh original reader. Uh so now we had the uh skimming equipment in place but the this company they use pin codes uh all day. So we had to get the pin code too and we had to have a place where we could sit and observe the pin code. So, what kind of place is the best?

Yeah, it's a white van. Of course, rented a white van. Placed it uh like 200 mters or so u away from the from the door. We were able to see the uh the uh keyboard sitting in the car with a sniper scope. >> The sniper scope was a bit overkill. I think it was like seven7 thou 78,000 for it. something we borrowed from a friend, but it was um yeah, we were able to see the code. People entered a little bit blurry picture because we used our phone towards the telescope and try to take the picture. I'll try to do a recording, but we were able you're not able to see the uh the digits, but you

don't have to see the digits. You only see the location of the finger. That's good enough. And luckily some people swiped their cards and we were able to read those cards. I think we got like five or six readings before we u very stealthy remove the reader again with some of the paint. Uh so this is the the data on the card. There's a I location ID and this um card ID. So when having this this data it's possible to make your own cards. So we used the prox mark and made cards and we tried to use that card and pin code and access granted. But when on the inside um we met a door to the server room. We we

were hoping hoping hoping that the card that we have got was um that we were really lucky and that that card also worked to the server room. But of course it didn't. So um yeah, access denied. So then we had to find another way of getting in. We have to uh we have access to the building. No access to the server room. We need to escalate the privileges on our card. How can we do that? Same thing again. >> Yeah, but then we have to hope for someone with the right uh permissions uh swipe their cards. >> Huh? >> Support ticket. Yeah. No, we just we hacked the access control management software instead. Much more fun.

I see now that I talk too quickly and the time is running way too slow, so I have to slow down. Um, yeah, we need to escalate the privileges, level up the card, but we need to get network access to be able to to uh find that software. But the problem now was that the um office wasn't empty. It was still full full of people. We heard people chatting. The server room was in the uh basement. And so when we first got into the building, we saw some stairs run down and luckily we saw the server room door and we heard people in the office. We heard a lot of people. So where do you where's the best

place to hide when you have to hide for quite a bit of time? >> The toilet. >> Just uh pretend that you have a real bad stomach or something. So um we waited for two hours in the toilet. Uh finally the uh the um uh office started to sound quiet and we took the chance and just started to walk around the building trying to find somewhere that we could sit and um do a yeah regular penetration test, an internal infrastructure test to try to find the um access control system uh management uh server and from there escalate So we started to connect to the network everywhere. They were using 802.1x port authentication. None of the ports gave

us access to the network. We only got access we got access to the guest network but nothing more. We didn't see any any interesting things. So, how do you bypass 802.1x? >> Printers. >> Printers, that's one option, but also IT employees office, they always have one point to test something. But printers is uh the go-to network ports when you're not finding anyone else. Uh so then we started to do gather information about the environment. uh doing port scans and trying to find whatever we could find. And luckily we found a server called uh SRV Stanley 01 or something like that. It was really really clear that this was the the um access control server. Um before we started the test, as I

mentioned earlier when I was talking faster than I do now, uh we said that uh we did a fishing campaign to get some credentials. Um when we tried to connect to this uh this uh access control server, we found that it replies on uh RDP and we just tried one of these uh accounts that we got got earlier. I think we got like I think we sent mail to 100 people or so and we got like 30 or 40 credentials as usual like uh luckily it's oh one reason uh all domain users had access to RDP to this uh access control server. No idea why. But when we RDP to it, it was in like

kind of like a kiosk modeish. Uh when you logged on with your Windows credentials, you were met with this. It's not so discreet. I tried to I removed the name. I already said it was a Stanley thing. You see the black and the yellow. Yeah. Um so how how do we find password for this was the next next question. Now we have access. How should how should we log on to this? We need to have more more info >> default credentials. >> Yeah, we'll see. So, next step, escalate access privileges on our card. And of course, we started with manual as you said, default credentials and tried all of tried this administrator, administrator manager manager

installer installed engineer engineer, income, and so on. And none worked. So, oh damn. Uh, but then we just did all lowercase instead. So, administrator, lowercase administrator, we're in. So, then we have had access to the uh this is in Norwegian. This was an Norwegian installation. Uh, access rights. So when when having access to this we use the ID of the card which was the ID that we saw earlier in this uh screenshot. One of the fields in the data here was the was the ID uh found the card changed the uh the access rightes. Um, so what now? Before I continue, is there any questions? Because I have 45 minutes on this. And um, yeah, I I said to Pat that um, it's not

a 45m minute talk, but yeah, you can use the time, but yeah, we'll see. Yeah. Whoa, many questions >> before you see how it goes. You can have some questions, too. What was your time frame on each of the phases from recon to going in the server room etc? >> Um we did the the fishing campaign but for the physical thing we only had two days. So we did the the fishing I think the week or two weeks before and then we went on site because it was quite a bit to travel. So uh we went on site did the physical recon one day and we did the attack in the evening and the day after.

So it was a a quick test. Yeah, looking at the group the user numbers there, was there any possibility to increment through those numbers through a brute force on your um >> that that could be that could be an option. Yes, >> it was possible. >> If we hadn't been able to uh hack the management software, we would have done that to try to find a user with higher privileges, but then we wouldn't have the pin code. So, >> Ah, yeah. Cheers. Oh, that's a lot. Okay, that's good. So, we can drag out the time a bit. >> So, this this building clearly had some physical security, right? They had codes and stuff. Were there no cameras? No

front desk person, right? You you were really able to get in and nobody noticed you were there for those two days. >> There were both There were cameras and there were front desk person, >> but we went in the back door because all the employees went in the back door and then we did the same. >> Uh cameras, there were cameras everywhere. But uh we heard afterwards that they were turned off for some reason. >> So then they didn't see anything. >> Why did they pay you for this? Like this was so easy. >> Yeah. Yeah. Yeah. It was a bit easy. Easy and easy. The having to decode the data and all and build the reader improvising that it

looks easy but it was a some Yeah. headache doing that. >> Yeah. >> I am really curious about They they considered doing a fishing campaign in scope for this. >> Yeah. Everything was allowed. Just don't >> Wow. >> Just don't hurt people and damage anything except the paint on the board. >> Okay. >> Cool beans.

One more and then we'll see how it goes. Maybe you can guess how it goes. Sorry if I missed this, but just out of curiosity, where did you get a box the perfect size and shape at that short notice? Uh there was this electrical shop, uh hardware shops focusing on electrical equipment. So, we just went in there and tried to find something that we were able to put everything in. So, we just bought a bunch and found found the smallest one that we could fit everything in. And yeah, it's not exactly small. Okay, one more then and uh we'll have more take more questions afterwards. There's a one. >> I'm not going to throw it. You can pass

it on. >> What was in your fishing campaign? >> Oh, uh let's see. What was that? Um the reason I didn't say anything about the fishing campaign is because I think that's that's not what I do. I think it's boring. So, I I get another guy to do that. But I think it was something micros some Microsoft thing that you have to refresh your access tokens blah blah blah blah blah something. Uh I can keep up now and it seems like there's a lot of questions so we can use more time afterwards. Uh so now we had the pin code for this card. where we had the uh we had the card tried it on the server room the uh the

outer server room opened. So when we entered that we got into the regular server room and there were this huge door on the next server room which like when you open these kind of doors you heard like so like pressurized and there's yeah it's an EMP secure room. So, it was really exciting when we took our card up to that reader, entered the pin code, and we're able to open the door. And when we did this, uh, when we act got into the room, it felt like, yeah, we were take do taking a selfie, sending to the contact person. It felt kind of like Mission Impossible. It was more like this.

So we sent this um this selfie to the uh contact person and uh he got got yeah surprised. Uh after we did the selfie uh as you remember the um objective of the test was to place a bomb inside the um in the uh in the room. So we had this pel case with some yeah just some electronics and stuff uh within it uh to just to be a simulated emulated bomb. Place the bomb. Then we needed to uh pull out uh get out we left the bomb. Uh we uh removed all the permissions on the uh access card because we didn't want that. We cloned the card. So the the person who had the original card also

had access to that EMP secure room for a while there. Um this was done late at night. So we hope that that person didn't try the card and they of course didn't. We cleaned up the permissions um cleaned up uh whatever else we left in the internal penetration test that we did to find access control system and walked out. That was it. That was it. And uh as I answered earlier on the question how long it took it was. Yeah. The fishing campaign was done in one day the week before and we did this in like two days. Two very long days. Uh 24 minutes. That's a bit low. Hopefully there's a lot of questions

then. I said to Pat 20 minutes but no. So that's it for the talk. Uh, it's Whoa. Uh, yeah, you can start taking questions, I think. >> Uh, so you guys weren't willing to pay for the keypad, but you were willing to pay for the $6 to $7,000 spotter scope. >> We borrowed it. >> Oh, >> yeah. >> We had a nerdy hunter friend. Um >> that that last slide you said you cleaned up on your way out. Did you have to do anything with the log or was there logs of like who accessed the >> Oh no. Um we didn't do anything about the logs. >> Oh okay. >> Yeah we could have but we didn't do

that. >> Uh what was your client's immediate reaction and what did they learn from this experience? Uh, I think they changed the access control system to something else than my classic and I also think they try to teach their employees to stand in front of the key panel when uh entering their pin code. It's they were quite surprised maybe that we got into the room because it uh and we too when we started on this test we did not think that we were able to get into the room. We had no idea how we how we should do it because it's it's a secure room. Uh only like two or three people have access. Uh the physical

security of the room is very good. Try to look at on the the it's a good uh high security Norwegian lock asablo. It's not possible to shim the door in in any way. There's covers in front of the latches and everything. So we had no idea how to get in. But uh so we were surprised and the customer were quite surprised too. >> There's someone I ask I brought it over here. Um could I ask why you chose to make that external box with as a skimmer rather than tapping the reader directly with something like an ESP key? >> Uh yeah, we didn't want to we didn't want to remove the reader from the wall

because we were thinking maybe there's some tampering going to alarm company and something or something like that. So, we didn't want to remove the reader from the wall >> because we have to remove the reader to get in to place the ESP key. >> Okay. >> On the wires and we were not sure either if they're using what kind of protocol is on the back side, if it's VGA or Yeah. Whatever. >> Well, isn't my for classic? It's almost always wagon, right? >> No, it depends on the reader. Uh, actually in Norway there's quite a bit of readers using some other serial protocols and Yeah. >> Okay. Thank you. Um, why do you think they gave you such

a short time to do the pen test? Was it because they didn't actually want you to succeed in the pentest? Because that seems like a really short time to do a thorough engagement. >> Yeah, but it's uh they gave us more time, but that was the time slot we had available to do the test. I think we had like a month or two to do the test, but we um delayed it and delayed it and oh, we have to finish this test. So, how did you figure out where the uh server room was? And additionally, what about the EMP room? Did you just expect it to be in the server room? >> Um, there's this uh fire maps in the

hallways the same. >> Yeah, we saw that there were this uh server room and there were another server server room behind the server server room and we didn't see any other server rooms on the uh the fire maps. Um, how many people were involved in this engagement? >> Two. H plus three. Uh, when the fishing guy was another one. >> Hey, uh, if you hacked the access management management system beforehand, could you skip the part of your installing all the physical hacking part? >> Uh, >> because you could probably create your own key. Yeah, but we needed to know what the format of the data on the cards. >> But if you have access to the

fullyfledged access management, you can bypass other stuff and just create your own key card with administr administrative privileges. >> Yeah. If if we had access to the place where they had where they have the reader, the writer, card writer and all that, we would be able to do that because the there's no place in the access control management software where you see the data format on the cards. >> Oh, so probably if you didn't have access to it, you needed to brute force all the versions of of the cards basically. >> Yeah. And it's that's impossible. >> Yeah. Cool.

So based off of this engagement, how would you rate it between your the other engagements for level of difficulty? >> Excuse me. >> Based off of this engagement, how would you rate it between your other engagements that you conduct off the level of difficulty? So would you say that this is this was easier than your other ones? >> Um do you find that a lot of the engagements that you do are pretty simple and as easy as this in wide open? >> Well, that's a really hard question to answer. Uh it's it's actually among the harder ones uh because it it's a really specific scope and there's a very few people having access into that area. Uh it's

not possible to tailgate in which we do on a lot of other um tests. So it's u among the harder ones before we it turned out to be not so hard but when we started on it we thought it was really hard. So yeah, >> did you have specific recommendations and did you follow up? >> Uh we haven't followed up. Uh the recommendations was to yeah as I mentioned earlier teach the uh employees to cover the pin when they enter the pin or maybe have something to cover next to the reader covering it. Uh also to change the the uh technology of the uh cards because the readers support like my desk which is much much better. Uh

but they use this old one. So I think that that's what that was a specific ones to um yeah use another technology on the cards. >> So uh I've got two two follow-up questions on what your client did afterwards. One, did they procure an EDR of any kind? And then two, did they interview the employees that were successfully fished to see if they had some afterthought of like, oh that seemed kind of weird? Because you know if you've got a self-reporting mechanism then you can flag a security team or your infosc person and like trigger to rotate credentials and cut off that that access. >> Uh the last one I don't know um I haven't asked them about it. Uh the your

first question were edr um I don't remember well if they had I think they had like defender a or something but we didn't do any we didn't use any exploits or malware or anything on the um we just scanned the environment we found the server with a name that matched the access control management >> but escalating the permissions on their on their employee account could have triggered a detection response if they were looking at their admin logs on their on their Windows server, right? >> Yeah. On the but it was only the cards. We didn't do any uh escal escalation on the uh servers. >> Yeah. >> Uh thanks, great talk. Uh just a quick

one about what the client's response and reaction was. you know, once you sort of walked them through what you found, um, how did they respond? What was their reaction? >> Um, they didn't think that we should be able to get into the room. So, they were quite surprised that we actually were able to uh succeed. Um yeah that's yeah and they were not aware of what kind of technology that was used on the uh access control system because usually they just buy a solution from the uh vendor and yeah don't in the documentation doesn't say anything about what's technology and so on. So yeah >> so you had um you had two doors to get

into that server you had the server room and then the EMP server room. >> Yeah. Um, you I think you mentioned that you're kind of doing this at night, but there are IT folks who work like night shifts and stuff. Like what was going to be your contingency should you open that EMP server room door and there be somebody in there doing work? >> Uh, >> and since it's such a small group of people that would have access >> uh uh I don't think we ever thought about that. >> Improvise. We'll make it when we get into there. Yeah. >> All right. Yeah. So you had a pretty easy time to get into that um like

access control panel uh like with the RDP and everything but what was your backup plan if that you you had like no way to to uh to get that easy admin admin access. >> Um there were no there wasn't any plan B to just improvise just >> you you were lucky and >> yeah we were lucky that worked. If that hadn't worked we just needed to try to find something else. That's what when you do test test like this, you never know what you meet. So you have to be very adaptive and able to improvise. Was it? Yeah. >> That room seems to be very critical. How come there wasn't any 24 hours surveillance through the cameras, etc.

from like a security company? >> There should be, but the cameras was turned off of some reason. I don't know why, but they're they're on now. I I hope >> just a question from me. Yeah. >> As well. So I mean if there's any of us here that um are responsible for securing something similar to that, what would you say are the three things that should be focused on? Not necessarily specific to how you breached there, but what you were trying to do to get in. What would you say are the three focus areas someone trying to secure an environment like that should be focused on based on what you were able to do? It

should be you should have the latest and best the uh better technologies on the cards using like myer Desfire or something like that. Desfire EV3. Um not everyone should be able to get into the uh access management software. You shouldn't use default passwords. Um so it's yeah don't use default passwords. Don't use all technologies. Yeah. mostly that >> cool but that that's all over the weak password the default passwords all technology it's not only in this kind of systems it's everywhere >> hey uh two questions do you know what prompted them to initially request the u pen test and then also did they give any insight into what were the factors that led to the specific failings like the

decisions to not update the the physical reader and like the ports being open and whatnot Yeah, I know. I don't know. Sorry even more. It was good that I spoke quickly in the beginning apparently >> for the 802.1 bypass. Were you working off an employes's computer or was that like a whitelisted port? >> No, it it was just a Linux computer that we brought with us. >> So, we didn't use the employees computer. just there were this uh Ethernet socket in the employees IT employee uh office and we connected there and we ran

>> I guess what was the plan if you were to have encountered like someone that might have stopped you or asked like maybe for an excuse to be there >> the uh the pretext you mean? >> Yeah. Um that too was maybe not planned as good as it should but uh the we we had like we had like uh ID cards with the company name and which looked like the company name and we the plan was to uh I think we had that in addition to cards from a IT vendor that they use. So the plan was to say that we were from that IT company doing something something. >> We've got time for two more questions.

>> Yeah. >> And I've almost done my steps for the day, so it's going well. >> Um I guess pivoting back to the 802.1x um problem. Um was there a reason why you uh elected to use your own computer instead of you know just uh trying uh credentials on uh like those fish credentials on a employee workstation? >> Because in our computer we have our tools. Yeah. Because yeah you need to use we used like end mapap we used the crack web exec and so on. It's not so easy to do on from your employee windows computer. >> Okay one more. Have I missed hands anywhere? One more.

>> So, with the whole RDP thing, were there recommendations on that? Did they lock that down or do they need to have that access to be able to do their jobs and stuff? >> Um, I don't know if they've done it, but we recommended that they don't have domain users as in the uh our remote user group. So I think we recommended that they locked it down to only the people who need to have access and also recommended that they change the password for the uh uh management access management software. >> Thank you very much Andre. >> No problem. [Applause] >> Thank you for showing up. If you still want to ask Andre any more questions,

I'm sure he can chat to you on the side >> as we get ready for our next talk, which will be at 3 p.m. [Music] Heat. Heat. [Music] By far down. [Music] Baby, [Music] daddy. [Music] Fire. [Music] Hey. Hey. [Music]

[Music]

Heat. Heat. [Music] Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat. [Music] [Applause] Heat. Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. Hey Heat.

Heat. Heat. N. [Music] Heat. Heat. [Music]

[Music]

[Music] Heat. Heat. [Music]

[Music]

What are you? [Music]

Heat. Heat.

Heat. [Music]

Hey, heat. Hey, heat. Heat. Hey, heat. Hey, heat.

[Music]

Heat. Heat.

[Music] Heat. Heat.

Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. [Music] Heat.

Heat. Heat.

Yeah, [Music]

[Music]

yeah yeah yeah. [Music] Heat. Heat. N. [Music] Hey hey [Music] hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey Yeah, [Music] down

down

[Music] Hey hey hey. [Music] Heat. Heat. [Music] Do

[Music] you [Music] Boo down. [Music] There you go. [Music] Black. [Music] Hey.

[Music] Okay, welcome to our next talk at Proscon. On this track, we are going to be considering what to tell your developers about NHI security and governance from a a seasoned speaker up here, Dwayne McDaniel. Before we do that, just a reminder to thank our sponsors, diamond sponsors, Adobe and Aikido, and also our gold sponsors, RunZero and Formal. A reminder you can take pictures of the speaker and the his content but no one else in the room please without their consent or anywhere else in in this venue without their without their consent. There's no need to record video as it is being recorded for us and streamed. So there will be access to that afterwards. So we'd like to invite

Dwayne McDaniel for what to tell your developers about NHI security and governance. Thank you much everybody. Uh thanks for being here. Um so I got I gave a talk yesterday. Raise your hand if you were in the talk yesterday. Cool. Because I'm going to repeat myself uh on a few slides and if you weren't here yesterday, you won't know that. So Kenton, don't give it away. Um I know Kenton was here yesterday. Um if you want these slides, I highly recommend it. I tried to narrow this down to less than 100 slides and couldn't do it. Um, I revamped this slide yesterday based on a couple conversations and realizing what I actually wanted people to take

away wasn't what the slides exactly said. So, you're seeing a brand new version of this. It does match the abstract. But with that, let's get going. But that's the tiny URL. That's your last chance. Three, two. If you would really like to go seeing their talk because there are awesome talks going on right now. Like I almost skipped this one to go to the proving ground one. Um, tell your developers if they see a plain text password, something's gone horribly wrong. And you need to work with them to solve that and make that right. Quick survey of the room. Who here works in security, quote unquote? I was besides, I would be shocked if that

wasn't the answer. Who here is a developer? Right on. This talk is not aimed at you. This talk is aimed at everyone else to have a better conversation with you overall. Any DevOps people in the room deploying infrastructure? Right on. Right on. On. Same qual or same qualifier to y'all. Okay. So, developers, DevOps people, I'm assuming the answer is yes to you. But raise your hand if you have ever deployed something that actually touched the internet that people you did not know actually used. Smaller room, but about half the hands gone up for people at home that can't see. Uh but something to think about because what I mean by that is you have built something that uses an

architecture of some form or another. It could be pass, could be SAS, could be you built it all. You could download the whole thing, could make Drupal and it's just one big monolith in a box and you pushed it through a build process that used get underneath the covers and it went all the way through and it had multiple tests and multiple acceptance criteria and multiple points and eventually you got approved and it finally released. So raise your hand if you've gotten through that and you've lived through all of that with a team. That's more than I anticipated. So I'm going to go through a lot faster through a couple parts here. But who's ever worked on a team where

they're like, "Get this done by this date." And you know the person behind you is uh that wants your job is going to take your job and they're going to replace you with AI very quickly if you don't do it. That is Hey, what's up? I believe you requested a whiskey. Red Bull. >> I did. Not the Red Bull. >> I missed the right. >> I I definitely I don't drink Red Bull. The whiskey sounds right, but >> I must have missed this time. Are we late? >> I apologize. >> No worry. I mean, I'll drink the whiskey, but I I I don't drink >> Well, so I I was not going to put the

whiskey and the Red Bull together because that's an abomination. >> That's an abomination. >> I was like, I will provide both, but I will not mix them. >> My my buzz buzz was starting to wear, so this is perfect. >> What What What is this anyway? the benefit of someone else's speaker request. So, >> thank you very much. >> There is one other speaker request.

>> A thank you so much for >> All right. Please, apologies for the disruption. >> Hey, no worries. I don't even remember what I requested. LA I'll never forget last year though. Last year I put my request to please accept the talk and they gave me a certificate that said I was the only person to ever have done that and I have that framed on my wall and it's one of the greatest treasures I own. Um, so nothing's going to top that. I don't even remember what I put. I think it was maybe donation to charity in my name. I don't remember. All right. Uh, again, because I'm going to go fast because a lot of you are developers, I'm

going to go real fast in this. Um, but it's no wonder that when people that are getting yelled at that have to go through all the hoops and like they need to close tickets and they are being judged on how fast they get the production out the door that when they turn to AI, which is exactly where I got this code, and it tells them to do something stupid, which is like literally chat GBT told me to do that about three, four months ago when I asked for this code. It's only getting dumber. So, um, I don't think it's getting better. I don't think it's like CHP is going to tell me to do it the

right way. So, it's no surprise when security goes to a developer and says, "Why are you doing this? Why you doing this wrong?" They're like, "You know how I work, right? You've you've seen you've seen the queue, right? Like, you know that they want to replace me with AI, right? You know that they there's a queue of developers around the street that will do my job cheaper and faster or at least claim to. And I want to drive this home because I think this is the most important thing that I don't hear from stage enough. We got to remember that everything we do in security is to get to this. This is a family enjoying an impossible game of

Monopoly. I'm not going to get into the minutia of why that's an impossible game because I I'm a nerd about board games. But that that's it. That is what security looks like when we do it right. There's no alarms going off. No one's ransomed. No one's in a panic. They are doing something they love with people they love away from the abstraction of computer science that we live in and we think is real. That's real. Well, the game isn't, but there's too many hotels like that. No, kids that young would never have that many hotels. All right, I'm off that soap box. But this is what good security looks like. And this is what a developer wants to do at the end

of the day. They don't want to worry about CVS. They don't want to worry about the technical minutia of security. They just want to finish the ticket and get home. I'm Dwayne. I come from Chicago. Help people figure stuff out. That's my entire mission in life. I got a really cool podcast. I think it's cool. We got good guests. I've had a couple people in the room on this podcast. I'd love to get more of you on the podcast. Um I love rock and roll. The band we were listening to earlier that probably didn't make it on the screen. It's called Tel Novella. They're out of Texas. One of my favorite acts in the world. I told you that too long doesn't

read works. Uh so this talk is about humans versus non-human access. I'm going to assume we all know how to implement pass keys and phto 2 and all of that good stuff. Now, I'm just going to assume that then your developers have been told this and you've got guidance in this and you have IM plans around that. The non-human side scares the hell out of me and that's what I want to talk about because if you go to developers say, "Hey, we're going to talk about nonhumans." They're going to be like, "What what do you mean non-humans?" Because that's like saying there's only two things in the world, a potato and not a potato. Um humans and non-humans.

Like, what do you mean non-humans? Well, I really like workload as a as a term here because that's really what we're talking about when we're talking about development. A workload is a running instance of software executing for specific purpose. Oh, that's still very broad, but that's not a car. That's not a ceiling. That's not a network. That's a running piece of software. So, that's a workload. That's a non-human that needs to authenticate to another system in order to do something. OASP definition is a little bit different. It says it's part of a larger application because, of course, OASP thinks everything's an application, and it is. I'm I'm a believer in that myself. But they actually go on further to say well

they use secrets in order to do those authentications and actually have that communication. Why is this such a big deal? Well in 2022 cyber said it's about 45 to1 the number of non-human identities that we're giving authentication mechanisms to versus every human that we're authenticating. Uh here in 2024 2025 or 25 what year 2025? Yeah it's probably closer to 100 according to research. Some people say it's higher some people lower. uh Cyberarch's own own research that it was closer to 78 whatever. This is about 100 to1 on this screen and now we live in aic AI and we're deploying APIs and things faster than ever and it's terrifying how fast we're deploying them. I've never seen this in my life

like how fast we're jamming out vibecoded nonsense. Uh I had a buddy who builds applications like weekly just for funds. It's like dude what are you doing? Um this isn't free by the way. Is I'm causing this as an energy crisis? Like that's another entirely different matter. Go nuclear. Um so why does this really matter? Because this is how crime happens. Now I didn't put the Verizon DVR numbers in here, but 22% of initial breaches are credential misuse. Uh that's a over 20 up uh that supersedes the 20% that is vulnerabilities and 18% of this fishing for initial breach access. uh cyber again last year said 93% of orgs had two or more identity related breaches in the past year. When

we say identity related, yeah, it could be logging in as a human and it could be those fishing things. But now based on the numbers and how hard web applications are getting hit and how hard CI/CD pipelines are getting hit and just the raw number of breaches that are abusive API keys that got leaked, stolen or somehow other misused because unlike people who have a sense of hey that doesn't feel right or fingerprints where you can like biometric or multiffactor authenticate in computers just say hey there's token I'm going to take it run with it. That was my entire talk yesterday. So, I'm not going to go down that rabbit hole a lot. So, how do we get out of this mess?

Well, the whole rest of this is about how we're going to put this plan in place. I'm not going to get into a lot of minutia about actual governance itself. We're going to go line by line through the top 10 risks for OASP here in a second, but it starts with raising awareness. So, that's the beginning of the conversation I want you to have. go back to your developers and say, "Look, we got a have a conversation about what's really going on in the big picture." That's nothing to do with your work. This is about the general trend I'm seeing. We need to be aware of the stuff I'm about to talk about, including the fact that you're building faster

than ever. And we recognize that. And then we got to figure out a better plan with you. We got to document and create policies that make sense and meet you where you are. And only then are we going to put tools in place that make sense. Now, that's green field. That's perfect. truly you're going to have tools you're going to have to mold into this and you're going to say all right we have policies around these tools already you're not starting fresh but unless we raise that awareness and it's not just their eyes glaze over because you're saying here's a new term for you and you're saying here's what it matters to you and here's why I need to get

involved because we want to be safe alto together and I am not saying anybody should print this and go to their developers and say here's a top 10 list for you please do not do that please please please do not do that because you will lose them immediately because you would lose me immediately. I read 90page PDFs all the time and I hate it. Hate it. Uh I like top 10 lists, but again I'm a nerd that likes top 10 list. Some developers might like this. What I'm suggesting is we go and structure the conversation in basically three big buckets and have this conversation with people over time and collectively with individuals, not just team leads, the actual impleers,

the actual devs and say, "Hey, we need to have this conversation." I'm steering this directly at the dev and the DevOps people. There's a larger conversation that needs to have with security. There's a larger conversation that needs with the rest of the team. We'll get to that. And it starts with ownership. That larger conversation can't just depend on your developers. It has to be everybody in the world that touches stuff, including the person who outright owns NHIS. And that's a big question mark. Again, that was talk yesterday was recorded. Does this person, the AM person actually exist in your org? Stats say no. Uh, unless you're five billion revenue or above. You might it might be a small company

that figured that out that someone directly outright owns AM across the board including your non-human identities and governance around that. Right now every company I know is scrambling to figure that out other than a handful like two of them are the largest car companies in the world have like they got that person and I've had that conversation with their um with their team their CISOs. But most companies I talked to are struggling with like who owns this? In fact, someone in this room was saying uh at one point call out who but was telling me like their team right now is trying to figure out who actually owns active directory. Like is it security? Is it is

it Greg? Who who owns this thing? And that's a larger conversation. But again, back on point today because I could talk about that as a whole other talk. In fact, I giant chunk of that talk yesterday. When we talk to devs, it's like, look, you're the one introducing these to the world. And we know that ultimately you are not the risker. You are part of the team that makes this risk happen. But we need you to take as much responsibility as possible to make sure we got it right going in. And I know that's hard, but we'll talk about making it easy as we go through this. But tell them ownership comes down to basically

adhering to governance policies. If you do that from your perspective, when you put these things in, know that you're thinking this through. If you open it, shut it. If you turn it on, turn it off. Does Ann Landers um sheep stole it from somewhere, but I don't remember where. But go look up an blame Anne Landers for that because if you Google that, what happened? If you Google that and Anne Landers, it'll be like the first thing that comes up if you go that list. All right, I'm gonna unplug it. Plug it back in. That always tends to do things. Maybe Ann Landers ghost like really doesn't like me using this. Like she is dead. Her daughter took over. I still

read Dear Abby every day. All right. Um, but this is Annland Landers. So, um, but it's basically that. I'm not read the whole list to you, but it's like basic common sense. And if we go back and look at the OASP top 10, how I've bundled this together. Now you might argue that like I put them in the wrong buckets for some of these. That's fine. This is my ideas, not OASP officially. OASP is the full top 10. But that first one's like on proper opboarding. So when you go talk to them about their code and the NHI is the non-UN identities they've introduced that have access to things like, hey, so when does this go out of service? Like what does

that look like? What's the offboarding process for this thing? And right now there's no good answers. They might have one. They might be like, "Oh, well this was tied to this system and when that goes out of service planned obsolescence in two years, we'll drop it and this is how we de decommission that thing." But I'm guessing if like anybody I talked to in development, they're like, "What do you mean? It's going to run forever. That's why we built it." It's like, "Yeah okay cool cool cool cool cool, cool, cool." So, what what does it look like if we did take it out of commission? Like, what is who's who would sign off on that? And you're going

to have some interesting conversation out of that. There's no good answer to when you sunset a thing other than when you run out of budget or time. But that's reactive. Proactively, do you have a plan around that? A good governance model will. Good governance model says every 18 months you're going to review this and see if it needs to shut down the next two. That's one governance model. There's a lot of writing about this right now. So there's no one true answer. So don't think I'm ultimate ultimate authority on NHIS. Overprivileged NHIS. Hey, are we scoping this as tight as we can? When you're scoping these, how are you doing scoping? And they just sit there and

listen. And you're going to be horrified by what you hear. But then you're going to watch the process they go through and it's going to look something like this. Who here has ever visited the DockHub authentication permission page before? It goes on and on and on and on and on. There are like 30,000 permutations for just GitHub. uh AWS combine all like 300 services times all that it's like 90,000 permissions that you could possibly do. So, it's not a real big surprise that when like my company did research into all the leaks, I'll talk more about like the scope or the size of the amount of leaks a little bit later, but when we look at the secrets we find out there,

like 99% of GitLab APIs or 58% I'm sorry, have full access and 96% of all GitHub tokens we find had right access with 95 offering full access to the repos. These are the ones we find in public. We know the private ones are even worse than this. About eight times worse. Um, not the scope permission, but the number that we find in code bases. It's not really a shocker because it's really hard. How do you help them narrow that down? And I say you in security, not the DevOps people because it's already hard enough on you. H how how are we helping here? This is an accusation. This is this is a call to action. This is if

you've never stopped to think about why are you over permissioning, sit with them and go through the exercise with them. And at some point, you're going to pull your hair out and be like, "Yeah, just set it wide because it will work that way." And I understand you have tickets to close and I we're wasting your other's time going through micro picking this out. But but but if you help them with tooling to figure out like, hey, how do we figure out what you're allowed and not to do and build scripting around that? Not saying it's going to be easy, but it's possible deterministically. Maybe maybe this is a good use for a uh AI with some tooling.

Maybe. I don't know. These are a bunch of questions I have. There's a bunch of conversations I've had. These aren't rock hard solutions. And reuse. Hey, is this NHI out being used outside of the one use case we just talked about? Probably. If it's a running piece of software like a database, absolutely it is. If it's a container that's supposed to come into existence to do one little thing, absolutely not. It's only supposed to do that one little thing. The bigger concern is like are we reusing the same NHI across environments? And this is just good old classic OASP top 10. Like are we allowing prod and pre-prod? Let's hope not. But until you have that conversation

with them and you they understand that like look you aren't yelling at me. This isn't something I've done wrong. You're just raising a they're not going to say you're raising awareness, but they're going to like no one's ever asked me that before. That's a good question. Huh? And that's how we're going to raise that awareness is by leading them down that path of like what are you doing? Not in a fusiontory manner like trying to understand. Guess what? The more notes you take on that, as my friend Sean says, if you write it down, you document everything, you're gonna have a pretty clear list of like, oh, this is stuff I need to clean up. This is stuff I need

to get on top of. This is where the training I need to help give people and help them through. This is a good one. Should a human ever be able to use this? Can you can set up rules. You can set up all sorts of detection rules to tell like allow lists and agents like did BTO3 call this or did a human over a Linux box called this in? Did did Ayda Love Lace the mother of all coding? Did she curl her way in to get to your user list or like why is JQ Q being thrown? A machine would never throw that. They don't need to. They can already read JSON. But if you don't know that they're

setting up a service count with the idea of like, well, I need to log in occasionally. There's a talk here earlier where they somebody did a screen test on a server they had no idea what they was doing. They just unplugged it, put a note on it with date stamp and like took them nine months to come somebody finally come in and pull their hair out and be like, "Look, you've destroyed a mission critical system." Like read the note. It's like from nine months ago because they were logging in with a service account to make sure a crown job was still running on an unrelated service using that service account that was tied to that box.

Crazy. But if you don't have that knowledge of like, you know, a human should never ever ever ever go down the same path and make this call like that this application workload should do. to them it's just another call. It's just another thing that you can hit with an API endpoint. That all goes under ownership and governance. Maybe I should have called it governance. I don't know. Ownership makes it feel more personal. Governance is like something we adhere to. Ownership is like, "All right, I have stake in this." And again, developer might say, "I don't care. I'm just checking boxes and getting the ticket done." And that's how some people are going to ask. Some people are going to

raise questions and be like, "I never thought about this stuff before. How do I do that better? And if you don't have answers to that and all you're going to do is accuse them of doing it wrong, time to rethink what you're doing. How are we helping them? How do we go from the department of no that everybody hates to the department of how do we do this properly and faster? Well, that's where the next piece comes in because the next piece is technically very achievable and it's stuff that you just need to raise awareness on first and then give them technical solutions on second. And then there's that technical complexity bit which is only

going to get worse as we go along. But that's something you're going to have to partner with them on no matter what. But we'll get to that. So, who's ever asked one of their developers like, "Hey, what's your time to live on something? What's your time to live on this this thing you set up? Like, what's the time to live on that that API a key? What's the shortest amount of time we could possibly grant it and still make sense?" And in their brain almost guaranteed unless they're already using jotss or already using PKI and be like what do you mean expire it just it's a key it just works until it doesn't work till

till you changed it or you made me change it like yep yep yep yep yep yep

yeah let's move on sake of time Um, I was going to say more there, but yeah, I only have so much time today. Uh, and then back to secret leakage. Again, these are all coming out directly off of the NHI top 10 for OASP. Uh, then maybe the most important one, like if you see a plain text credential, say something. This is the heart. And I put it in the middle of the talk, like pretty much the dead middle because that's the pinnacle of the conversation. And if they say, "Well, I'm doing it because that's how we do it." You have an organizational problem. There is something that needs to be addressed much wider than just that person.

If they say, "Oh, you mean like in Jira, like when we occasionally write things in Jira, it's like, yes, that's exactly what I mean. We shouldn't be doing that. There are a bunch of better solutions. Let's pass it around through one password if we have to pass it through. Let's figure out how to properly use vaults very quickly. This goes real quick. I say secrets, credentials, keys, certificates um tokens connection database, connection URLs, all in the same word in my head, and I know there's fine detailed differences between all these things, but I'm just going to say secret. We're going to move on. Everybody's going to be happy that I mean all of this laundry list of thing.

You can disagree with me later, but that's what I mean. Sorry. Sorry. So when I say secret, that's what I mean. When I most of the time when a developer thinks plain text credential, this is what they actually are thinking about. And again, this is a Python example that uh chatbt gave me a couple months ago. I don't think it's gotten better since that says here's your access token. So it's like, of course, that's how they're going to do it, especially if they're in a hurry. It just needs to work, right? Cool. It works. Good. Move next ticket. We'll worry about the security aspect later. You're going to get yelled at months down the line, but maybe you're not even

going to be there anymore. Maybe a take your job already. It works. It introduced risk. Ah, but risk you can live with. It's a business after all. We know that that's an ongoing concern and something that we even though we've been saying it for years and years and years and years and years in the industry to don't do that. We know it's getting worse and people keep doing it. just from looking at public code on GitHub. And then for the first time ever, we did the research on our internal customers, put out this report. It's not gated. It's just go download the thing. Do it through tour. We don't care. Just just go read it because it's

got a lot of great info. So, I have a really terrible gift. Actually, I got a couple. One's kind of cool. The other's terrible. Um, we're going to play a little guessing game. If you did this yesterday or you know the numbers, don't play. But close without going over. How many secrets do you think we found hard-coded in GitHub public just in the year 2024 that were added just in the year 2024 on GitHub and public? And we to preface this, we look at every new commit that hits GitHub and everything that becomes public on GitHub. We look at all of those events and you can too. API.github.com/events. So we look at every single commit. We

scan it for a secret, email the committer and say, "Hey, you did this. Don't please don't do that." And then we move on with our lives. Um, but then we save all of that data and we put out this report. That's where the numbers come from. So, how many how many secrets were added to GitHub public just in the year 202400? >> Which who I need hands because I can't see you. >> 10,000 >> 10,000 >> 5 million >> 5 million >> 100,000 >> 100,000 >> million >> 10 million. >> What? >> 100 million. >> 100 million. No, >> two and a half million. I think 10 10 say over 10 million was the So 10 23.77

million is the the answer. Um so 10 million. Is that you? Is that you? That was you. All right. Here's a terribly crocheted hacky sack. And I have a flashlight that I'm not going to throw at your your head. Oh my god. >> You sneaky dude. You did ask for something. >> Oh, I did. Oh my god. >> You requested a tiny trophy. uh presented to me just for asking. So there you go. >> Yay. I have a tiny trophy I got just for asking for it. I will treasure this award. It will go I'll put a little shelf right above my award from last year that I got just for uh asking for them to take thing. And

they wrote on it in gold Sharpie. >> Only the finest. >> Only the finest. And they I think everything's spelled right presented. Yeah. Yeah. I think they corrected it, but yeah, it's spelled right. All right. Yeah. So, I do this for again something else for you a little sec later, but um I do this in a fun little like jokey way, but that's a terrifying number to me because that's 4.61% of all repos someone posted to. That's 15% of all committers did this last year. Uh this is a 25% growth from the previous year. We changed our methodologies a little bit, but we've seen consistent 25 to 50% growth year-over-year since we started doing this report in 2020.

So that 70% valid number. Um so we do a quick validity check of every secret we find to see hey does this work? The system come back and say this works and if it does uh we say that's valid. Um we took a subset of what we found in 2022 11,070 or something like that and reran the same validity checks in because it's still public. They didn't take them down. um ran it again in 20 uh January of this year 2025 and 70% came back is still valid. Yeah, people ain't rotating. So that's that is the crux of the previous two. So when I combine them, I'm like, hey, how long is it supposed to live? That's different than how long

is the NHI supposed to live. But permission set, like how long is this supposed to expire? Uh should have a plan around that. How fast do you rotate these things? Is it in plain text? Is it in plain text? Is it going to be almost impossible to rotate? So, can we move to a better authentication system to deal with all of this? Because in sure authentication is something we're going to be dogged by forever. And the answer is yes. And I'm going to go real quick. So, whiplash on this one. There are standards coming like Spiffy and the reference implementation Spire that are coming that are going to give the developer a way through an API to inject a name

space. uh spiffy ID into workload upon birth and then let it rotate automatically from the back end what that certificate actually says and then allow list it through the system to say you have the spiffy ID you're allowed to go in here and then we're going to separate out the concern of authentication from authorization hopefully at scale because Google's been doing this for over a decade you can do this through spire there's an awesome book if you read nothing else because of me read this book spiffy.io/book. And if you're like, I ain't got time for 198 page free book, which is really entertaining. By the way, uh there's one of the best presentations I've ever seen

in my life. Uh it's from Matias and uh Tom back at Cloud Native Security Con that talk about this in depth with cute pictures. Uh I just actually told Cyber today like you really need to make a comic or um a coloring book out of this and help people understand this concept because it's so fundamental. But it's coming really quickly. It's not just cloudnative people that are saying this uh the internet uh engineering task force you know the people that maintain the standards that make the internet happen like HTTP and IP and TCP those standards same people are working on workload identity and multi system environments we're on draft 4 right now it's the same idea of spiffy of

namespacing and allow listing for processes at a very fine grain level that separate out authentication and authorization that's where my workload definition came from earlier is from their actual documents. You can go join the mailing list. It's pretty pretty active right now. There's some big disagreements on protocol right now, but that's what we make these standards. We're all having conversations. Not going to get into the details of it, but you come up and say, "Hey, I am me. Okay, here's your application DNS or your process DNS record. That's you. Cool. now we'll let you in the gateway and we'll worry about certificates and certificate what you're actually authorized to do once we're in the trust boundary

and you're like well that sounds futuristic nah it's in core of kubernetes now so it has been since May you can go read it great article from uh any um but basically you issue these shortlived automatically rotated tokens for your service accounts and when it needs to do an image pull it trades that for a token lets it do it expires And that's how it works now. It's one of the options you have since May. Same idea that we're going to move to these ephemeral federated or federated identities with ephemeral secrets. Can't really leak these things because if you leak a jot that expired 15 minutes after it was issued, it's a very short window

for an attacker to attack. So, they're going to need to know that's all coming. Right now, they're like, I have no idea what you're talking about with Spiffy and this stuff. That's a team meeting. That is a architecture meeting but overall it's going to save them time. The spiffy book spells out in a giant chart. It's like five hours a week you can save your developers by getting away from they have to hand set permissions and worry about all of the minutia of how to deal with API calls and all of the credentiing. you just take that off their plate and say here issue it a credential when it's born or not credential a yeah um um yeah

credential a naming space a name space when it's born a spiffy ID when it's born and the system kind of flows after that there's a lot of minutia to that but that's the future that's coming 3 to five years I think that's going to be the standard way we do everything across all systems but right now how are you authenticating to SAS and other thirdparty systems that are way lagging behind You could roll your own spiffy right now for your internal systems. You're you should be for Kubernetes. How do you do it for these systems? I don't know because right now they're hard coding it. So how do we get away from that? Well, we use secret managers. If they're

not already using secret managers, this is the time to get them on board. This is as important as MFA in my opinion, maybe more so because of the scale of the NHI problem. Again, 100 to one versus every one person has MFA. Machines can't MFA, but you can fault in secrets at runtime through conure secure connections from places where they're being stored at rest. And that's exactly what a cloud secrets provider is. If you're not all in one cloud or you got a bunch of legacy laying around, there are solutions. Are they free? No. Well, one of them has a free version on the screen vault. Um, but it's free as in puppies. You're going to have to

maintain it. You're going to have to actually deal with it. Uh, but the trade-off is very, very much worth it. And instead of hard coding a secret, you hardcode a path. And if I'm an attacker and I see a path into a vault, it's like, now I got to get into the vault. Man, now I got to get into the vault. I'll figure out another way in. Maybe I'll look around for the vault key. It might be in a secrets.txt file. Who knows? But now I know I have to get into a vault. And that's that's a hard much harder problem than just, hey, here's an AFK key and it just works. Speaking of just working, I don't know

what's going on here. I'm not stepping on stuff. I promise. Unplug it. Plug it back in. Oh, there we go. Wiggle in. It worked. Sometimes that works too. So, the benefit of this, and this is what you can tell the developer directly, of like, I know this is a pain and it sounds like this is way harder than hard coding a credential, and it might be a little bit of a learning curve on it. Thank you very much. Um, but once you do that, we will handle the rotation for you. I will never come back and say, "You need to rotate this secret." You're never going to remember what permissions you set because we'll have access to that from the back end

because that will be logged. We will be able to do analysis on that based on the fact it's in a vault. If it's a good vault, based on our tooling, we can use these pre-written things in our system, uh, pre-written scripts that exist with all these cloud providers and all of these other tools that will let us rotate that. And the developer's like, "What do you mean?" So, like, I don't hard code it. I never have to replace it. You're never going to bug me about it ever again. Like, yep. And if they still say that sounds like a terrible idea, say all right, let's keep opening bugs, man. Like that's get your bug count as high as possible. So when

you get reviewed, you'll know that you refuse to do this safely. And if they still refuse, that's between them and their manager. That's risk a risks risk acceptance right there. And of course, this all works through third parties as well. If you can't rotate an API key with an API call, it's 2025. Ask why that's pos that's not a thing. Move to a system that you can do that with. And all of the providers like Cyber Vault, Doppler, all of them, all the enterprise have the same scripts. They will help you with those scripts. Figure out how to do that at scale because they want you to rotate these a lot more often than they are. Again, the

shorter window that a machine token lives, a machine secret lives, the shorter window the attacker has to actually do anything. But Dev's got a lot going on. How do we get them to adopt adopt these quickly? Well, first you explain the significant effort that they're going to have to make of continually maintaining and updating these secrets and they're going to have to remember what they did and you're going to bother them and it's going to take them weeks of their lives or they can do it right the first time and you'll never bother them again. But they're still going to say, "But it's still slower." In the short term, it's going to be until you figure out

how to meet them where they are. I'm going to go real blazing fast through the next pieces. But I think Git is the greatest thing in the world. I've worked for two companies with Git in the name. I've taught well over a thousand people Git basics. And git is amazing, but you have to understand basically what it's doing in order to understand the real magic of it. And understand all your developers under have a very different understanding of git than the other developers on your team. No one ever sits down and says, "Hey, you have to learn git from first principles." That might happen. No, there's an awesome git book and I highly recommend everybody read it even though it's

outdated. Core principles are still all there. Um, but most people know eight commands, maybe 16. And then people use gueies, which I'm not against. I love guies. who get cracking. I love those people. But uh it's automagical to them. They don't really understand what's happening. Short primer on git. Promise two minutes. Git is this awesome way to track what happens in the file system over time. You can take snapshots at any given time. Those you're checking in and saying, I want you to track these things. I made a change. Cool. Now we have a different version of that thing in my in my history. It does this by compressing the actual objects themselves that were changed. If

it didn't change, it just points back to the last time it was changed and say, "Hey, down the chain, that's the version of this thing I last changed." Otherwise, takes and makes a little compression using the z-lib library and throws that into an index, a single file that we call the index. Um, so when you do a git ad, that's actually what it adds to that compression of a blob into this one piece of list. basically uh it's in binary and then we say get commit and it makes a permanent record of that in the git tree. If you're like that sounds like blockchain. Yes, blockchain all came from this. It's this story paper actually talks about git and

this exact phenomenon that we are chaining together these blocks of blobs and these points of proof. Now the awesome part is you have a permanent memory of everything. The downside is you have permanent memory of everything. Meaning, if you committed a hard-coded secret and you didn't and then you took it back out in the next commit, guess what? The commit where you put it in is still there. Unless you did some kind of weird surgical maneuver where you destroyed that commit and you got everyone that's ever touched that repo ever to agree to your changes. Good luck with that. And then hope there's no shadow cache of it. Guess what? There's a shadow cache of it on GitHub. Um, and

no one else that ever saw the code made a copy of it that you don't know about. That's also the power of Git. Everyone can have a copy of all the code. Buried in Git, though, is this thing called hooks. Uh, hooks is awesome because hooks lets you do anything you can damn well figure out. Uh, it's just a scripting trigger mechanism. You pass a threshold in the workload and it triggers the script to run. So, pre-commit, it's probably the most popular one. Uh, post commit or not post commit, pre-receive, um, you can do on the server side and the user side. Uh, there are 17 and all. Go giths.com great explanation deeper than I get into

today. this is what all of GitHub actions is based on. Like they're like, "What if we took GitHubs and made it available on the server and they called it GitHub actions?" That's that's the history. It's a little more detailed than that, but that's all I got time for today because I'm oversimplifying. But you can make these scripts do anything you damn well please. Like hacking has dad joke. I still run this. So when I do a manual uh successful um commit, it tells me a dad joke because why not? So why don't we build good hooks that say hey you tried to plain text your credential developer let's not make that commit happen. Let's stop the commit. You can halt it. And

now let's go check on your vault to see hey does this exist secret already exists in the vault? It does. Cool. Here's the here's the path into the vault that you need to hardcode. Well let's just let's just use some said or x or whatever o maybe and just swap that out in the exact line that you did that on. Bring it up for review and say hey would you like to commit this instead? This isn't sci-fi. I've seen this work. Uh, if it's not there, let's store it in the vault and make up a path. That's a little trickier because of paths are weird, but again, I've seen it work. It's just weird looking paths, trust me.

But we can get in more of that later after after this talk. Uh and then your system should be if we ever commit a new path, we should rotate whatever's on the end of that path once it's hits uh the once it hits the um the shared repo. But that should be a GitHub action you have set up for our PR check run. But dev's going to be devs and they're like, I don't want to run that locally. It's like, well, of course that would save you time and everyone a lot of time and a lot of effort, but they're going to get around it. they're going to ignore their git hook sometimes. Uh so

why not do that exact same thing at the PR level with some scripting with GitHub actions or whatever runner task runners you have on your git system. Again, exact same thing but at the PR level. So was it exposed in that PR? Yeah. Did we rotate that secret automatically on the acceptance of the PR and we replace that hard-coded secret with the vault call? Yeah. this is how we're going to help them do their job a lot faster and safer once we convince them that hey we'll build you an IDE but if you don't know how to get works and you don't know how to script and you don't know how to build an IDE

it's a lot harder to meet them where they are so that's my other challenge and call to action for everybody is learn the basics learn how git basically works learn how hooks work and learn a little scripting bash ain't hard it's confusing it's really deep but basic bash scripting you can pick up an afternoon oh yeah and there's a reference implementation for everything I just talked about. It's called we called it brimstone. Cyber called it something else, but it's it's out there on GitHub. The notes are in the um speaker notes or the links in the speaker notes. So the last piece of technical complexity on this list, there's no easy answer on here, but tooling is going to

help us. And it's that ongoing conversation, and this is something you should already be having with them, like how can we help you not deploy insecure code? And it's not just here's a tool. It's like, can we help you understand that you might expose some serious dangers here? Not just risks, dangers if we do this in an insecure way. And how can we help you stay in compliant? We're going to be monitoring for policy violations. They're going to become bugs. We're going to come back and we don't want to yell at you. How can we help you stay in compliance? I think part of that is explaining the way we view the world for posture

management. I have a whole other talk about security posture management but at the heart it's just answering these basic questions like are we checking for this stuff are we securing it now some stuff anomalous traffic there's no way they can deal with but we can help them with tools and let them know that this is what we're checking for and if there is a local tool that will help them if you know how to get hook work with Git hooks you can start tying it in and help them automate the process and again tie it into your GitHub automations or GitHub action automations if they miss And back to the virtuous cycle. Help them raise awareness. Help put processes

in place that they can follow. Give them the right tools. Tools come last in my opinion. And then help train them on those tools to follow the processes, to follow the documentation. Again, there's a whole other talk we could have about human authentication, but I've really been focused on nonhumans. I'm just going to skip. There's a there's a whole world of tooling that is emerging right now and how you look at this problem of non-human identity. I think it come down to those four things. This is from the well the non-human identity management group. Those four like questions in the bigger picture that you need to ask and your org needs to ask and you need to have the

conversation globally with all stakeholders and developers and everybody. And there's a ton of tooling. Again, if you're not having the ownership conversation about how you do this and what you think needs to happen and the policies you need to set, none of these tools are going to solve this for you. There's no magic wand here. This is a giant organizational problem. But together, we can solve it. But that's the three buckets I put it in and know that if we don't deal with this now, we're never getting another chance. AI, building the AI is coming. And if we don't put the governance models in place right now and have the conversations with the devs that do exist, the humans

who can control this, maybe we just need another profession because the breaches are only going to get worse and they're logging in. They ain't breaking in. So if they see a plain text secret, have them say something. Then work with them to figure out how to not make that happen. I'm Dwayne. I got opinions on things. Obviously try to help people figure stuff out. Hopefully I didn't confuse anybody. Don't worry about that. That's just where I work. And there's the links again. So, thank you very much. [Applause] >> That was not great whiskey. >> Thank you very much, Dwayne. Thanks everyone for joining us. The next talk will be at 5:00 p.m. Thanks everyone. [Music]

Heat. Heat. [Music] [Music] Baby, [Music] daddy [Music] doo. [Music] Do you know [Music] hey

Heat. Heat. [Music]

[Music]

Heat. Heat. [Music] Heat. Hey. Hey. Hey. Heat. [Music] Heat.

[Music] Heat. Heat.

Heat. Heat. [Applause] [Music] Heat. Heat.

Heat. Heat. N. [Music] Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. Heat. [Music]

[Music]

[Music]

[Music] Hey, hey hey. [Music] Heat. Heat. [Music]

Wow. [Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

[Music] brother. Heat. [Music]

Heat. Heat.

[Music] Heat. [Music] Heat.

Heat.

Heat.

Yeah, [Music]

[Music]

yeah yeah yeah. [Music] Hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey. Yeah, [Music] down. [Music] Down

down down down down down down down.

[Music] Hey, [Music] hey hey. [Music] Hey, [Music] hey hey. [Music] Heat. Heat. [Music] by [Music] Baby, [Music] daddy. [Music]

Heat. Heat. N.

[Music] Black.

[Music] Hey. Hey. [Music]

[Music]

Heat. Heat. [Music] Heat. Hey. Hey. Hey. Heat. [Music] Heat.

[Music] Heat. Heat.

Heat. Heat. [Applause] [Music] Heat. Heat.

Heat. Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music]

[Music] Heat. Heat. N. [Music] Heat. [Music] Heat. [Music]

Wow. [Music] Heat. Heat.

[Music] Heat. Heat. [Music]

Heat. [Music]

Hey. Hey. Hey. Heat. Heat.

[Music] Heat. Heat. Heat. Heat.

[Music]

Heat. [Music] Heat. [Music]

Heat. Heat.

[Music] Heat. Heat. [Music] Yeah, [Music]

down. [Music] Black. [Music] Yeah. [Music]

down. [Music] Down. [Music]

Yeah,

[Music] [Music] D. [Music] Hey, hey hey hey hey. Hey. Hey. Hey.

[Music]

[Music]

Heat. Heat. [Music] Heat. Hey. Hey. Hey.

[Music]

Heat. Heat. Heat. [Music] Heat. [Applause] Heat. Heat. N. [Music] Heat. Heat. [Music] Heat. Heat. N.

[Music] Heat. Heat. [Music] Heat. [Music] Heat. [Music] Heat. Heat. N.

[Music]

[Music]

[Music] feel me. Heat. [Music]

Heat. [Music] Heat. Heat. [Music]

Wow. [Music] Heat. Heat [Music]

up [Music] Heat. [Music]

Heat. Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. Hey. Hey. Hey. [Music] Heat. Heat.

Heat.

Heat.

Yeah, [Music]

[Music]

yeah yeah. [Music] be back. Hey Yeah, [Music] down. [Music] Down

yeah down.

[Music] down. [Music] That's [Music] Heat. Heat. [Music] [Music] down. [Music] Down. [Music] Hey, [Music] hey hey.

[Music]

[Music] Heat. [Music] Heat. [Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat.

Heat. Heat. Heat. [Applause] [Music] Heat. Heat.

Heat. Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat. Heat. [Music] Heat. [Music] Heat.

[Music]

[Music] Heat. Heat. [Music] Heat. Heat. N. [Music] Heat. [Music] Heat. [Music]

Wow. [Music] Heat. Hey, heat. Hey, heat. [Music] Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. [Music]

Heat. Heat. Heat. N.

Heat.

[Music] Heat. [Music]

Heat. Heat. [Music] Heat. [Music] Heat.

Heat.

Heat.

Yeah, [Music]

[Music]

down. [Music] be [Music] hey [Music] black hey black hey black hey black hey black hey black hey black hey black hey black hey black hey black hey black hey Yeah, [Music] down. [Music] Down

down down.

[Music] Hey, [Music] hey, [Music] hey. [Music] [Music] Heat. Heat. N. [Music] Do you [Music] buy me? [Music]

Down. [Music]

Down. [Music]

[Music] Heat. [Music] Heat. [Music] Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat.

Heat. [Music] Hey Heat.

[Music] Okay. Okay. So, we'd like to welcome everyone to Passwords Con to the next uh talk that we're having. Just a reminder, um we'd like to thank our diamond sponsors, Prismacloud Invant, and our gold sponsors, Adobe and uh Simgrip. A reminder about um your phones, please put them on silent so that the speakers uh not interrupted or anyone else in the audience. If you want to take photos of the speaker or his presentation, are you okay with that? >> Sure. >> He's fine with that. Please remember the policy not to take anyone else that is attending without their consent both in here and and outside. So, cracking 936 million passwords. How is that going to

work? Well, we're going to have Jeff Dick take us through that. So, Jeff, you're up. >> Thank you. Can everybody hear me? >> Excellent. >> So, I'm Jeff. This is my talk. Um, if you go to jdify.com or dyick.com, you can see a PDF of all these slides. So, a little bit about me. Nothing very exciting. Read at your leisure. If anybody has any questions during the talk and they're short questions, ask me. If they're long questions, save it to the end. So, there's a thing called Have I Been Poned? You've probably all heard about it. They have a way of downloading all of their passwords. You can't download them in plain text, but you can download

them hashed. So, I got these in NT landman format. And 936 million. Um, so it turns out you need a lot of RAM to crack passwords. So, you can either use a CPU or a GPU. I found that a CPU worked much better. So, I started off with 128 gigabytes of RAM. I upgraded to 256 GB of RAM. If I had deep pockets or somebody wants to pay me $1,000, I can update to 512 gig of RAM, but that hasn't happened yet. Um, yeah. So, if you want to do this in a timeefficient fashion, buy yourself some RAM. Um, and I found 92% of them so far. So, the tools are John the Ripper and

Hashcat. Hashcat is primarily a GPU accelerated way of breaking passwords. Turns out it didn't work especially well for me. Um, it it's a common tool. It does it does work. It just didn't provide a lot of passwords per second. So, John the Ripper um they they don't make a lot of official updates. Neither does Hashcap, but they make a lot of unofficial point releases. Um, John the Ripper doesn't really work too well with GPUs. I don't know why. It just doesn't. Um, the good news is is that the way to break passwords is to have good dictionaries and custommade rules or good rules. That is by far the most efficient way of finding passwords. And

the other thing is they have extremely great support. Um, hashcat I'm using 626, which is the latest version, three years old now. Um, I was using a 3060Ti GPU. If I used a faster GPU, it might be five or 10 times faster. It still wouldn't have made much of a difference. Um, the rule syntax. So, imagine you want to insert an alphabetic character in the first position. With John the Ripper, that's one line. With Hashcat, you have to have one line for each character. So, now imagine that you want to insert a character in the first position. in the second position all the way through to let's say the 30th position. Let's say you want to insert 100 characters. So

that's 30 * 100 characters. That's 3,000 lines of rules. So they say they need to do this to run quickly. Maybe it's true, but I'd rather have one line and debug one line and show you guys one line of a rule than 3,000 lines of a rule. Um, and the dictionary attacks for hashcat I found were taking up a good amount of memory. My hashcat machine had only 16 gigabytes of memory. I tried it on another machine with 120 gigabytes of memory. It just uses a lot of memory to do what it does. So, word list, I don't know if you guys download Word List. Most of them are pretty crappy. Some of them are pretty

good. I found that um Rocky, either 2021 or the previous version of Rockyu is very good. Rocky 2025 I downloaded. It's very big. The quality is not so good. Um, so when you download these things, they're full of junk. Most of them except for Rocky. Some of them have lines that are hundreds of thousands of lines of characters long. Some of them have random junk in them. Trying to curate something that's 10 gigabytes or 30 gigabytes is very difficult or impossible. So good quality word list is mission critical to breaking passwords in a timely fashion. So I wrote a bunch of tools to help me with this task. I wrote a program called short which will truncate a file and

only pro produce the first x characters whatever that might be. So if you have a 100,000 character line you can knock down to 50 or something. I I presume nobody's got 100,000 character passwords. I've never heard of one. Um there's m sort which is a merge sort routine. It needs to have more physical memory than you're trying to sort but other than that it works very well. What else do we have here? We have multi merge will merge a bunch of things so it runs quicker. Um I have sample which will sample however many every 10,000 every 10,000 lines or things of that nature. Uh, I have things that produce line length statistics, counts of asky

characters. I have some password utilities that I wrote and I have some sometimes when the password is found, it's got unprintable characters and so they encode it in a hexodimal format. I have a thing to turn it into binary stuff. It's called password unhex. I also wrote some password statistics programs to give me statistics on the passwords I found, which I'll be showing you later. So there's standard tools. GNU sort is an excellent tool. Unique com um I use Emacs as my text editor. I know not everybody likes it, but it'll handle gigabyte files. It will handle binary data. It'll handle pretty much anything. Is somebody have a question? Okay. So relative hashing speed, if you look at nand man, it's the

fastest hashing algorithm. That means if you want to break it, it takes the least amount of resources. If you look at DSC, which is a tool I used, the passwordized breaking previously, it's much slower. DSC crypt, I think it came around in 1978 or something like that. So why nand man is such a fast algorithm, which means it's basically weak, I don't know. If modern Linuxes, they tend to use things like brypt, which is substantially slower. So if these passwords were encrypted with B-crypt, I probably would have found very very few of them. So you should be using a hashing algorithm if you want your password to be secure that's slow. And if you want to make it easy to break,

you should use it one that's fast. So salt, does anybody know what salt is? I'm going to Does anybody not know what salt is? Come on. Somebody's got to not know. Everybody knows it. Yeah. Okay. Very good. So in 1979, people figured out if he's got a password that's password one 123 and he's got a password that's one two three, the hash is going to be the same. So he said, "We're going to add what was it? Uh 14 bits of random data to each person's password. So the chance that his password and his password when hashed are going to be the same is one in 4,000. So the reason you do this is it makes it very difficult to do a

rainbow table attack." So again, they figured this out in 1979. I'm guessing that's older than half the people in the audience, but Windows doesn't use salting. I don't know why. I've never heard anybody give me an explanation why it doesn't use salting. So that's very good for me breaking passwords and very bad from a security standpoint. So in the 80s, Unix went up to 48 bits of salt, which is a huge number. In 1996, BCrypt used 128 bits of salt. So the chance of having a collision is one and two to the 128 which is a very very big number. So good for me. Anti- land man no salt. Those things run real quickly. So

the tools I used dictionary attacks is the most efficient way to find passwords. You just encrypt the dictionary word. You compare it to the hashed word. If they're the same, you found your thing. So the brute force attack. Let's say you want to break all of the eight character upper lowerase and number passwords. So that's number of combinations. I'm not going to read it out. It took me 229 days on my 3060Ti. I think I got like four million passwords that way, which is actually not a good number in terms of passwords per second. Um, and the the problem is even if you can do that really quickly, let's assume you can do it in a day. When you go to

something longer like 12 characters, things scale up very very quickly. And so it just doesn't matter how fast your GPU is. If you add one character your password, it's going to run 30 to 80 or 100 times slower. So it does not scale. um 16 character upper lowercase number that's number and that's how many years it would take me to crack it with my GPU which is pretty much forever if that's a cryptographically strong password. So the efficient way is use a rulebased attack which I'm going to come to next. So I'm sorry rainbow tables people say use rainbow tables. Rainbow tables are awesome. So I downloaded what was the thing? I think it was nine

characters and upper lower numbers and symbols. It was very very slow. I've got the statistics here. Oh, if you want to do this, Defcon's got the data duplication village. You bring them a six terabyte hard drive, they'll fill it up with rainbow tables. So, the numbers are I'm sorry. Do I I don't um It took a long time. I thought I'd put the numbers here. One second. H well, I'll tell you the numbers. It took I think it was like 500 seconds to crack one password with rainbow tables. That just randomly accessing a file was stored on a solid state hard drive. So if you have 100 million passwords or 900 million passwords, it's going to take

forever. So I don't know why Rainbow Tables took as long as it did, but it was very slow. I'm okay. So, here's Rainbow Crack. So, I downloaded the nine character lowercase and and alpha and spaces thing. It's 43 gigabytes. It's a good amount of space. Um, one of the tools I was unable to get working, but eventually I found a tool. Where is it? Oh, I sent in a bug report for Project Rainbow Crack. Never got a reply. Um, oh, I also also the memory used I figured out that if I wanted to do it the 936 million passwords, I'd need 150 terabytes of RAM. So, that wasn't going to work. I don't have that much RAM.

So, I used what's our crack iT worked. I was impressed. So it took 6 seconds per file. There was 84 files. 504 seconds is what it took to break one password. So I used the password I knew was in that nine character set. So if you scale that up, that's 16,000 years to try all the nine character passwords. So I don't know why I was as slow as it was. I used a SATA SSD. If I would have used an NVME SSD, it might have been five times faster, but that still wouldn't have helped me. So if you have one or two passwords, go with Rainbow Crack. If you have 100 million or 900 million, it's not going

to work. So Hashcat, my machine for Hashcat had 16 gig of RAM. Um, I decided to try it on moving passwords and it took 660 megabytes of space. So assuming it scales up linearly with that, it would take 624 gigabytes of RAM to run that. So I don't have that much RAM. So I decided not to use hashcat with dictionaries. So if if you have small dictionaries or small numbers of passwords to crack, it's probably fine. I mean, a million passwords is a lot of passwords. So, I can't really fault the hashtag guys for using 600 megabytes of RAM, but if somebody wants to break 900 megabytes of passwords, not going to work. I'm sorry,

900 million passwords, not going to work. So, now we get to the rules. John the Ripper has the best rules. So, rules, they take a standard word from a dictionary and they modify it in some way. Um they have a very very verbose set of rules and you can make custom rules which I did. Um so I upgraded my machine from 120 gig to 256 gig and when you run this it takes a fair amount of memory and you can run multiple forks which will multiply the amount of memory. So one fork would take I don't know what say 20 megabytes of memory. So six forks sorry gigabytes. So six forks would take six times that. So as the

number of unfound passwords decreases, the hashing speed stays the same, but you can use more things in parallel at a time and so you can increase the effective throughput of things. So when I first started this using the default John the Ripper rules, I managed to find 487 million passwords in 12 days, which is like half the passwords. That was pretty cool. And also since the number of untime passwords decreased by a factor two, I could double the number of forks. So that was a really good thing to do. Um that that was the lowhanging fruit. So John the Ripper has a very good default dictionary. It's very very small and using that I found 154 million

passwords. That was really good. So there's an incremental attack which will never ever terminate and It starts off pretty quick and it slows down unfortunately pretty quickly. So I found 320 million passwords. So these numbers are not all exclusive. These are like inclusive numbers. So they would add up to more than the individual numbers. Um so then I started using the Rocket U word list. So I found 156 million passwords that way. And then I bought the 256 GB of memory so I could double the number of threads I was using or number of forks. Um so yes I started doing attacks using the default word list and the default rules which is all the rules and I found

another 15 million passwords that way. So just for context using hashcat and I think all the nine or 10 character passwords I found four million passwords in half a year of time. So this is really really fast compared to a brute force attack. It's going to miss things. It's not going to get everything, but the speed is so fast, it's better to reduce the number of unfound passage you have and then crank the number of forks up. So my computer has 64 cores and 128 threads. So I can scale this up quite a bit. So I started off with seven forks and then I said, let's apply the rules twice. So if one of the rules is uppercase the

first character, the second rule might be append a number at the end. So it would take a long time and probably never terminate. But I found another 36 million passwords that way. So then I decided to not use the standard word list but to use the Rockyu 21 2021 word list. I found 265 million passwords in less an hour. That was super awesome. Um, so then I was able to increase the number of forks up to 18 after I found all those passwords and I was able to run things like more than twice as fast as before. So I found another 11 million passwords in three days with that. So the thing with finding passwords,

you find the easy passwords first and you find them quickly and then things slow down and they slow down at about an exponential rate which is really unfortunate. But the good news is the more password you find, the less that are unfound and the more forks you can use. So when I was done with this, I was running about 30 one or 32 forks in parallel. That was the limit with the amount of RAM I had. So I did a brute force attack of all the characters up to nine. Um, so I found 16, I'm sorry, 3.6 million passwords that way and it took four days. And then I had 811 million found passwords which

is a good number. So I started using that dictionary of found passwords. All all dictionaries have different qualities but these are all real passwords that I really found. So this is like the highest quality dictionary you can get. And using that dictionary and the standard John the ripper rules I found another 16 million passwords in seven days. And you basically just wait for the stuff to slow down and once it gets too slow, you say, "I'm going to finish. I'm going to stop this because it would take years to finish. So the good news is it finds things quicker quickly than slowly. And at some threshold that you get to, which for me was like a character a second, a

password a second. I'm just giving up on this." So then I started to apply the rules twice on my 811 million found word dictionary. And yeah, it would take it would take years to finish. So with the simple things like just doing a brute force attack on a dictionary, it would take like minutes or an hour to finish. But this applying the rules or applying the rules twice, it the the CPU usage goes up exponentially. So now we can run with 10 forks and let's see I was using the Rockview dictionary and I was down to 129 unmillion 129 million unfound passwords. So I used a special rule that I wrote to replace a character with a control

character. So if the password is password one two three, I say let's replace the first character with a control character. I ran through all the control characters. I said, "Okay, let's replace a second character with all the control characters." And I found this when I was breaking my DScript passwords that some passwords have control characters and the standard dictionaries and the standard rules don't really look at that. So, the good news I have statistics on how many control character passwords I found and there's a good number of them. So the second thing I did was instead of replacing a character was to insert a control character using the Rocku 2021 dictionary and I found another 8 million passwords pretty

quickly with that. So these are the control character rules. So if you look at the optimized version that's one line long and that will do an over strike of a control character in any position no matter how long the password is and it includes uh 80 which I believe is delete fire call correctly and it includes all the standard control characters. So it's not very readable but it's only one line long and the rule to do the insert is the same thing. It's the last line, the optimized version. The unoptimized version still works. It's just not as fast. So, I can deal with a oneline rule that that's something I can show you and put

on a slide. I can't put 3,000 line or bigger than that rules there. So, here's hashcat and hashcat performance. So, lower, upper, number, and special length seven took 3.7 days. That's not so bad. Then you go up to eight characters and it's 10 days. That That's not so good. Then you have lower number passwords of length nine. That's 5.3 days. But the last one I ran was a lower number of length 10. 180 days. I found 2.4 million passwords. That's really not a cost-effective thing to do there. Okay. Um and and you know, if you increase the length to 11 or something like that, you're you're pretty much hosed. And even if you have 10, 50, 90

GPUs, it's still not going to be a good day for you. So this is just not an efficient way of finding passwords. If you only have a few passwords, this might be a good way to do business. When you have a lot of passwords, it it's just not a scalable thing. So I pretty much gave up on hashcat after the thing that took 180 days. I said, I'm done with that. I turned the machine off. So here's some password statistics. This is the length of passwords. So for example, passwords of length one 0% overall 275. This this includes duplicated passwords and it goes all the way up to 30 plus. So this is really interesting because if

you look at it, most of the passwords are like eight or nine characters long and this doesn't show the password I couldn't find. But the statistics on 869 million passwords. So this is pretty good statistics. I've not seen this anywhere else at a password talk. So I wrote my own program to generate these statistics. So this is for example like all lowercase was 18.9%. But then I have like all uppercase or all special characters. I just made these these rules up. But the control characters will include unic code stuff. So I got 269,000 passwords that had control characters. Um, 8bit ASKI is stuff where the most significant bits turned on had 128,000 of those. But if you want to break

passwords, statistically speaking, the lower digit stuff is 43%. So that's that's where you want to go to break your passwords if you want to get as much as you can, as quickly as you can. Just statistically speaking, I know your people's passwords, but I'm guessing most of them are going to be lowercase or lowercase in numbers. And again based on 869 million found passwords. So now we have string classes. So all alpha is just alphabetic characters. So alpha number is alpha characters and then numbers after that. So that is 35% of all the passwords. So a password like password one two three. But then we have like numbers followed by alphas which would be one two three password. That's

that's a lot less common. And I just made up more things. Numbers alphas numbers and all kinds of stuff. And I think this is very interesting statistic because this shows how people construct passwords. Obviously, these are not cryptographically strong random passwords. But the these numbers don't add up to 100%. But I got a lot of passwords this way. So if you wanted, you could make a rule that says, let's go find, you know, six alphabetics than three numbers, for example. And that's a whole lot faster than saying all lowercase and all numbers together. And again, statistically speaking, you'll do pretty well that way. Um, yeah. So, here's the control character. This is the fun stuff. I got eight new

lines. I'm sorry, eight uh line feeds. Character turns, 20 29,000 of those. Uh, horizontal tabs, that's a tab character, 134,000 of those. Delete characters, 1,045. So these these are all in principal things and yet there's a good number of these in passwords. I don't know how they put them in. I don't know how they got through whatever password screening process they have there. There's a fair number of control characters and these are these all came from my custom written rules to find non-printable characters and passwords. Do you have a question back there? >> Speak up a little bit more. Speak up. I can't hear you. >> Yes.

>> So that is a possibility that so the question was is the password I found could have been a collision with a real password. So hashes can have collisions. And so if if the real password is happy Tuesday, but password 123 happens to have the same hashes that there would be a collision and I could find an incorrect thing. So that would be unfortunate that I wouldn't get the true password, but I would have a password that would generate the same hash. And so if I was breaking into computers, I could use my collided password just as effectively. you. So, the statistics would not be good, but the potential to cause damage with it would be 100%. With

a collided password hash, does that make sense? >> Very good. So, defenses don't use antman. Why windows uses nand man, which is the fastest algorithm and doesn't have salt, I don't know. 1979 people invented salt. It's a long time ago. It's a It's a long time ago. Why Why are they're not using a slower algorithm than Nland man? I don't know. Even MD5 is slower, you know. Not that MD5 is cryptographically strong, but Linux is using Brypt. BCrypt is very, very, very slow. So, two-factor authentication always a good thing. There's this the stupid phone text message, which is crappy two-factor authentication. There's hardware security modules such as a Yuba key or Google's Titan key or a PIV card that

has built-in secure thing. There there's a lot of two-factor authentications. So, if you're doing something involving money, you probably want to have a two-factor authentication so somebody didn't steal your money. Um, use cryptographically strong random numbers or random strings. If you use a password manager and it generates a 20 character cryptographically strong password, it's not going to be a dictionary attack. It's not going to be found by a brute force attack. You saw how long it took to do a brute force attack. You know, pick pick your favorite length that you think is good, but make it more than eight characters long. So, I wrote a cryptographically strong random number random string generator in Python. These are some

examples. It shows the number of bits of entropy. So I don't use any of these passwords but I can generate these things and I can make them whatever length I want and I can tell you only use numbers or only use uppercase or only use whatever and I can make 30 character passwords if I want. So is this better than than a password manager? Absolutely not. But I wanted something that was simple and portable and quick and I wrote it because it's only you know like 50 lines or something like that. But none of these passwords are going to be in any dictionary. You're not going to be able to remember these. So, you need to use a password

manager. I like local password managers. I don't want a password manager in the cloud because I don't want to worry about data breaches. Key pass is an excellent open source password manager. You can write your own. You can there there's a whole bunch of good open- source password manager. You can even host your own. I forgot what it was called. There there are things that you can host yourself that that run in your private cloud to do this. But I can't memorize these passwords. Maybe some of you folks memorize one or two, but I use a separate password for every different system. I probably have two or 30 hunds. I can't remember all that stuff. And

what's better is it you can't torture me and I can't tell you the password because I don't know. So, if you're using a GPU, you're going to want to undervolt it and underclock it to reduce its power consumption. Less power, less heat, thing will last longer. Some some underclock better than others do. I could get like 10% power savings, which is still good because the thing ran a couple degrees cooler. There's some random links here. Um, the open wall guys are the John the Ripper. There there's lots of good sources of password information. Here are the dictionaries that I was using and how big they are. Some of these are good and some of these are

bad. But like week pass 37 gigabytes, Rocky 2021 96 98 gigabytes. These are not small files. If if you want to throw them into an editor, you better have a lot of RAM or you better split them up in little pieces. Uh some of these are good, some of these are bad. I like Rockview. It it works well for me. It's shown high quality stuff. But get yourself a fair amount of storage if you're doing this. Is that the last slide? Maybe that's the last slide. Any questions? I believe we're gonna get a microphone for people to ask questions.

>> Anybody?

>> Hi. Since you noticed such a large improvement using that uh specific word list, do you uh I imagine you were curious and went and investigated how they had come up with it in a way that was different enough to get that large of a a difference. What did you find out? >> So I don't know where the the providence of it, but it's allegedly from a datab. So they they they claim that it's an actual leaked list of passwords and statistically speaking I was getting a lot of good data from that as opposed to other stuff. The very best dictionary I was using was the one that I found my 900 odd million password thing because I

found all those passwords. They were real passwords and when you start applying the rules to already found passwords you get pretty good performance. But I don't know where Rocky 21 came from. I I they say it's from a data breach. >> Well, I guess what I'm wondering is do you believe that that's just uh unmodified u results of that breach or do you think that there are transforms applied to that to produce the given the size? >> I I don't know. I'm I'm guessing that it's a raw breach, but but I don't know. The thing is applying transforms you're going to I mean if you just like uppercase the third character you're going to double

>> right >> the the file size. If you say uppercase one character you know in each position you're going to multiply the thing by like a factor of 10 or 20. So >> so so anything that would be like a reasonably straightforward rule you would expect to have someone just implement that as a rule >> and you would increase the size of your file. So instead of uppercasing what you subtract you substitute a number for a a letter. So you have 10 characters that's gonna each each character position is going to multiply the size of your file by 10. So if you have you know length 10 passwords that's going to be a 100 times

bigger file. So I doubt that people augment the the raw results with different rules because that would just increase your file size like the last example would be by a factor of 100 which really sucks. Nobody wants to download a file 100 times bigger than they have to. >> That seems to make sense. Thank you.

Thank you for your talk. Uh I have a small question. Would you find that uh mutating the passwords and generating a new dictionary is faster than mutating the passwords in memory using rules? >> So I believe that they do things more or less sequentially or possibly in a batch mode. I don't think they there is a way with John the Ripper to apply a rule and write the whole file out, but I think that' actually be slower. I think you'd be limited by IO speeds as opposed to reading the thing in and just doing it in memory, I I presume since each thread takes like 10 GB of memory. No, what what I meant is

if you had like a pre-processing stage where you took the rules that you found and you created a new dictionary before running JDR, would that have helped running things more efficiently or is it more efficient to run those rules in memory on existing inputs? >> I think it's much more efficient to run them in memory on existing inputs. I think you'll simply multiply the size of your dictionary by pre-processing it with the rules by a factor of 100 or a thousand and I don't have that much disc space. Thank you. >> We got we got a whole bunch of questions. He's got some there. Couple back there.

Uh you gave a lot of examples of the formats of the passwords. I was curious if you did any analysis or had any data on the I say longer passwords like 12 or 16 characters or longer if those were just combinations of words or like what was the complexity of the longer passwords that you found? >> I didn't look at that. Um but the the problem when you've got like 12 character passwords. So I've got what is it here? Five 50 million of them. I can't look at 50 million passwords and get statistics from I could have written a program to see what they look like, but I didn't bother with that level of detail. The

thing is there's very little people that do statistics on the password sound. I could write something so for characters, you know, longer than 10 characters long, try to get some statistics on how they're formatted, but I haven't done that yet. It's certainly interesting future work.

So um just a question you know you've got a you got a pretty good corpus of data here yes that that you've built up >> is there any opportunity to use machine learning or or AI as we call it now um to use that to inform creation of better rules and better mangling uh to in essence speed things up. I would guess the answer would be yes, but if you have to feed in 869 million passwords into a LLM, well, no, you would create a new model at that point. You wouldn't use an LLM. But I I guess what I'm saying is is I I wonder if those patterns if run through you know several uh you know models and layers

and the tensors if you would be able to come up with some call it groundbreaking rules for that mangling. I am certain you could find some interesting rules. I don't know how groundbreaking they would be and I don't have the resources to do this AI processing on it, but I think that's excellent work and now that LLMs are becoming more of a thing. I think it's going to be the future of password tracking because obviously you want good rules and right now we say okay let let's insert a character or let's insert two characters and you know you want to know which characters you want to insert. I mean, maybe vowels are good to insert. Maybe numbers are good to

insert. Maybe tildas are good to insert. And I don't know what I don't know what the good characters are, but presumably an LLM could figure that out. >> So, a follow-up question. Uh, do you have a GitHub where you posted all these goodies? >> I do not. The these are relatively large files as you would imagine. >> Well, more your rules and process. >> The the rules. So, the one custom rule I wrote I have on my slides. The other rules are John the Ripper rules. The only one that's a unusual rule, it's in it's in their list of rules, but they have something they call OI2, which is insert or over strike two characters.

They have an OI1, but the OI2 found a bunch of passwords for me, but it's in the standard John the Ripper distribution. So, the rule, let's see, do I have the rule here? I'm sure I do.

Yeah. So, these these two rules are the the ones that I wrote myself. The good news is the guy in charge of John the Ripper is a guy named Solar Designer who's a Linux security engineer, and he optimized these for me. I don't really understand the syntax of the stuff, but they work. And it's two lines, so anybody could write down those two lines and get the insert or overstrike of control characters. And I asked them to put in delete in there. So that's what the H0 is. That that's hex for delete ASKI127 I believe. Um but it certainly an interesting question. >> Yeah. No, thank you. Anybody else? >> We we got a microphone.

As a quick one, did you uh explore uh since you you looked into GPU acceleration, did you explore alternative hardware, FPGA hosted stuff like on a big XYX part or something like that? >> So, John the Ripper has some acceleration for a really, really, really old FPGA. I think things like eight or 10 years old. And these things are hard to come by and they're not nearly state-of-the-art. I don't know of any current password cracking people that are using modern FPGAAS, but in terms of price performance or performance per watt, an FPGA is going to beat a GPU. The thing about GPUs is they're made at huge scales. The price are driven down by volume and gamers

love of, you know, 4K 100 frames per second video games. So, it's good good for people cracking passwords like me, but but it's never going to be as efficient as an FPGA. Thank you.

I have an assumption that you know a lot about hashing in every flavor. What do you like? You like Argon Blake uh for a modern hash? >> So, BCryp or Argon are state-of-the-art algorithms. So, they're both nice and slow. They're both cryptographically very strong. Let's go back here. I don't think I have argon listed here, but it it's a modern encryption or modern hashing algorithm. So, the thing is if you look at nand man, it is so weak and and you know Microsoft came out with Windows 7, they came out with Windows 10, they came out with Windows 11. Surely they could have picked a better hashing algorithm. Surely they could have implemented 12 bits of of salt or 36 bits of salt or

some reasonable amount of salt and they haven't done that. So why their hashing is so fast and they don't use salt I have no answer for. Maybe Bill Gates or the current guy kind of running Microsoft could tell you that but I certainly can't. But but I mean look at BCrypt. be crypt. It's 13,000 hashes a second. And and look at nan man. It's 41 million hashes a second. I'm sorry. 41 billion hashes a second. Why? Why? Why make it so easy for people like me? Why why make the hashing algorithm so insecure? I don't have an answer for that. It it it's certainly inexcusable. It's certainly that they knew better, you know. Oops. 1979

is is when salt came about. 1979. It's 46 years ago. It's a long time. Even if it takes them a decade to implement this, they should have done it, you know, well before 2000. I I don't know why they're not doing it. It's not a new idea. >> Sure. Um on your slide there, I saw WPA2. Have you played with uh cracking WPA3? I mean, it's got some defenses, but uh >> I have not. Okay. So, so the reason I used the NT landman version of of the have I been pawned, it's the fastest algorithm. Why? Why? So, I think they also had I don't know what it was. I think it was it was maybe it was Shaw

one. I think I could get the passwords in Shaw one. But why should I pick Shaw one which is so much slower when I can pick Landman which is super duper fast? I I want to crack passwords. I didn't want to melt CPUs and you know use gigawatts of power. So, I did this all my my main computer. It's sitting in my house right now. It's getting like 15 or 20 passwords a second, and it's going to slow down, but that's not so bad. That's with 10 threads. When I get home, I'll probably take all the found passwords and make my unfound password substantially smaller. Probably increase number of threads by five or six. I mean forks, not threads.

So, they're actually separate processes forked. Thank you all for coming. [Applause] [Music]

[Music] [Music] Back down. [Music] Hey, hey hey. [Music] Heat. [Music] Heat.

Down. [Music] Hey. [Music]

Heat. Heat. [Music] Heat. Heat. N.

[Music] Heat. Heat. [Music]

Heat. Heat.

Heat. [Music] Heat.

[Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat. N.

[Music] Heat. Heat. N. [Music]

[Music]

[Music]

[Music] Heat. Heat. [Music] Heat. Heat. [Music] Wow.

[Music] Heat. [Music]

Heat. Heat.

Heat. Heat.

[Music] [Applause] [Music] Heat. Heat.

Heat. Heat.

[Music]

Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. [Music] Yeah, [Music]

[Music] down. [Music] Hey, hey hey. [Music] Yeah,

[Music] down down. [Music]

[Music] Heat. Heat. [Music] Okay, welcome everyone to Passwords Contract the 6 PM talk. Just a reminder to thank our sponsors Adobe Diamond sponsors Adobe and Iikido and also our gold sponsors Drop Zone AI and Profit. Obviously with them and all our other sponsors, volunteers and of course you guys are what makes the conference what it is. So, thank you very much for that. Just a reminder, if you have a cell phone, you can take pictures of the speaker and his uh presentation, but please don't take pictures of anybody else in the audience without their consent or anywhere else for that matter. There's no need to record anything. Uh it has been recorded and streamed already. They'll all be

available to everybody afterwards. Cool. So, let's get into it. Uh cracking hidden identities, understanding the threat surface of hidden identities and protecting them against password exposure. Introducing or is it Hey guys, how are you doing? So I get the slot in which everyone is a coffee and a cake. I'll try to do my best and not bore you to death. And uh if you have any questions, feel free. I'll also leave 10 minutes at end for Q&A. Today we'll be talking about hidden identities and risks that they impose to the business. And first of all presenting myself just so you get context to whether I'm just you know a clown that infiltrated bides or do I actually

provide some sort of additional information and my name is Orish. I'm the co-founder and CEO of LX security. We're a browser security company. That means that we track what employees do online. Online is where they do stupid. stupid as a big factor in uh password weaknesses and all kinds of identity risks. In the last decade and a half, I'm doing primarily AI development and security research and um in historically I was uh leading takedowns of uh botn nets and putting people in jail. So if you do break the law, make sure not to use your own devices as a testing environment to uh for your malware because then people may get your data and understand who you are. All right.

So, a little bit about what Linux does just so you get some context to what kind of data uh we have and what we're trying to do. We're a browser security company. We have a tool that's get deployed as a browser extension to any browser and using that we just analyze what employees are doing. And the claim to fame or what we're trying to get is actually seeing what employees do in real life. So, that's kind of like you know uh videos of what your pets are doing when they're at home. We have that experience with users in their uh day-to-day environment and we see what kind of activities they do without asking them to make any kind of uh

changes to what they do. So our database or our data sources actual activity of users whereas most organizations where they try to apply identity security policies they fetch data from their IDP from their intra etc. So that's about us today. We'll be talking about a couple of things. We'll understand what are hidden identities and what there are so many of them. I will understand a little bit of the risks associated with credentials on a hidden identities and then discuss a little bit of what can you do about that. I'll use a little bit of analogies during that. I like analogies. It doesn't mean that I'm that good with analogies but just for you to expect. Um and I want to start with

going backwards from when you know something really happens badly. Uh by raising your hand how many of you are actually practitioners within uh security teams of companies. All right. So effectively when you like in most organizations when you uh do your day-to-day work especially in security architecture you you try to get the best of version of yourself as an organization so you get prepared for the doomsday. So getting as much as possible behind federation with MFA with all kinds of security controls in real life when a sheet storm happens, pardon my French, there will be something that's unexpected. For example, someone calling help desk and removing MFA um or some sort of an anomaly or some sort of a

user just lost his device somewhere or just I saw someone in the hotel at David just connecting to his Gmail from the FedEx office because he just had to print something. All of those things turn real life a bit dirtier than it is. So uh I believe that how good you are in theory in real life you'll be at best 80% of that. So the real question is how good are we at at our full potential because in real life we won't really really be that good and the question is what really existent in the organization that's super critical and that relates to hidden identities because account takeovers are pretty much a big deal and

SAS usage in the organization is very you know interesting before we talk about in identities let's talk a little bit about SAS security and identity security um web browsers are pretty much 32 years old so we've went in a shift from which you know all the data and all the users were being set in one location one building uh and that's it all the rest is a jungle it's all evil the internet is a dangerous place I actually had the pleasure of talking to a CISO that doesn't allow internet access in his organization still today fortunately that's not very common especially in the in North America and over time there started to be some sort of a shift to

using all kinds of SAS or early versions of SAS or early version of connectivity private access traditionally really really differentiated. It's either personal or work everything has some sort of a client server relationship really differentiatable on the host name level to a world in which over time we move to really full shift to full SAS you have you know notion or chat or whatever and then chat GPT can have a million accounts those million accounts can represent some like you know anything um now let's take for example Dell technologies del technologies acquired EMC a couple of years ago let's say that you you know if I was a security practitioner within Dell which I'm not I would not be surprised to find

anything like there is a chance that they have an EMC chipd account they may have a Dell EMC Dell CHBT account that has an investment arm DTC they have accounts uh they have all kinds of activities you know some users use WhatsApp to pass business information what is LinkedIn what's workrelated what's nonworkrelated and what are the boundaries to really disallow users from doing things eventually in real life I can share an example I have a client that had a a an account takeover uh coming on a personal webmail. So they just attacked his personal Gmail and using that to communicate with peers and colleagues. This world is starting to be really really um meshed or like really

gray. It's really hard to differentiate between you know good and bad with regard to user activity. Eventually all of that is becoming the battlefield of interactions between users, applications and data because eventually malware can become can come from my personal you know uh outlook can come from my company outlook. uh most companies actually exclude on the firewall all traffic going to Azure, GCP, AWS just because it's really hard to inspect all of that. So in this world the identity in SAS account context really matters. My personal CHPd is evil for my organization. My company license chipd account is really great. If someone takes over my personal chipd account, no one really cares. But if someone takes

over my account uh of the business context, that can be used to actually do lateral movement into company resources. Putting aside a note that um adopting AI inside organization shatters micro segmentation because that AI may have access to anything. So what really happens in real life statistically across all kinds of customers that we have users use over the course of 90 days about 25 SAS accounts that are mapped using some sort of an identity provisioning. What does that mean? If I go into some sort of a site that doesn't use an identity or there is some sort of an exotic authentication mechanism that would not be considered SAS. So we transfer just having a a a a page that I

can just download something from. That's not SAS. SAS is me using my Facebook, my LinkedIn or my work applications. And that's what's happening within the course of 90 days. Naturally over a year it's way more than that because some users actually don't log into their bank account in 3 months. And then comes the question in within the work context how many of those are you know good. How many of them are bad? So we have differentiation between uh on the identity level between corporate accounts and non-corporate accounts. It's unrelated to the usage of those accounts. Over twothirds of all SAS used by employees is actually non-corporate related. So in in the identity context so my LinkedIn which is definitely an

instrument for work. I set meetings using my LinkedIn. I actually communicate with people. That's not work on the identity level. Under a third is corporate related. And within those corporate accounts, we have a distinction between accounts under federation and behind SSO and those that are not behind SSO. And here again, we have a nearly half and half. So all the things that are in the red are things that eventually IT and security don't really control. Uh but they are really really really existent within the organization. That's a majority of user activity is done on accounts and SAS applications that no one really has any effect over. And I'll use this movie which I really like as an analogy which

is you know the good, the bad and the ugly. Eventually a lot of the things that are in the environment are are a necessary evil. We can't really avoid them. It's it turns really political, really messy and then you get into realities in which uh you have a password found on a data breach related to someone's you know dating app and that password is being used on another account and that password is also used on a business account and the ideability of an attacker to chain nonwork and work identity is becoming more significant. A good example for that is h