BsidesLV 2025 - PasswordsCon - Wednesday

Heat. Heat.

[Music] Heat. Hey. Hey.

[Music] Heat. Heat.

[Music] feel. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. [Music] Black [Music]

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

Black.

[Music]

Hey. [Music]

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

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

Heat.

[Music] Heat. [Music]

Heat.

Heat.

Heat. [Music]

Heat.

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

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

Heat. Heat. Heat.

Heat. Heat. N. [Music]

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

[Music]

[Music] Hey. [Music] It's [Music]

[Music] Heat. Heat. [Music]

Woo! Wow! [Music] Heat. Hey, Heat. Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat.

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

Heat. Heat.

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

Heat. Heat.

Yeah, [Music]

[Music]

yeah yeah. [Music] Black. [Music] Keep it back. Yeah, [Music] down. [Music] Down

down down down down.

[Music] Heat. Heat. [Music]

[Music]

Heat. Heat. N. [Music] Good morning and welcome to Besides Las Vegas Password Con. This talk is password cracking in ad the fun part of compliance given by Scooby. A few announcements before we start. We would like to thank our sponsors especially our diamond sponsors Adob and Akira and our gold sponsors drop zone AI and run zero. It's their support along with other sponsors, donors, volunteers that make this event possible. These talks are being streamed live and as courtesy to our speaker and audience, we'd ask you to check to make sure your cell phones are set set to silent.

With that, let's get started. And please welcome Scooby.

Okay, today I will tell you a story. A story about three groups. YOLOP uh company that follow compliance rules uh but that do not have any security staff in the company. Coolsec a company with security pros that understood that yes compliant is important but sometimes it's better to use your judgment. And finally, evil cats who obviously do not know, do not care about security or do not need to be compliant, sorry, at all. My name is Matthew Sonier. I'm currently working at Spectre Ops as the product manager for the Bloodown Community Edition product. And sometimes after 20 years in this industry, I feel a little bit like this. While I was preparing this talk, and

yes, that was back in 2023, I watched this webinar from the Black Hill security folks where they talked about the 10 things that they did the most often, or rather that worked the most often to breach their customers. And if we zoom a little bit, we can see that the number one methods, the one that worked the most often was related to passwords. Their solution very easy longer passwords. So during this story we will see just how much password length influence password strength and resistance to attacks. When we search on Google, everybody agrees that passwords are in fact the weakest link. So should we just get rid of them? I've worked for at least two corporations

that went passwordless while I was working there. And it was very very nice not to have to type any passwords to get into most of these systems that we had. Maybe except the your computer or your laptop in some cases. Uh but there's a lot of reason why the company you are all working for today might not be able to go passwordless. So if that's your case, you're in luck. This presentation is for you. So now that we've set the table, let's meet the folks at YOLO Corp. And this was built uh this these image was built at the very beginning of image generation uh by AI and it has evolved a lot but I wanted to keep the original

image because I kind of like them. Anyway, here is YOLO Corp. Uh they all look super cool and carefree. It's very hard to imagine what could actually go wrong, right? Uh well, we'll see that soon enough. YOLO Corp is compliant to both PCI and GDPR. Now, let's introduce the people at or the folks rather at cool. Here we all can already see that things are more serious. Coolsec is also compliant to both PCI and GDPR but also they decided to follow the NIST recommendations. In this story we will see just how the three of these standards are impacting passwords and finally meet evil cats here. It smells like trouble. Um, I'm sure a lot of you here in this room

have seen the Kiwiccon poster that lists all of the things that hackers do not care about. Well, our friends at Evil Cats are exactly like that. But on top of that, they have the unpleasant and arrogant attitude so typical of cats. I should know I got two cats now, and I even get some battle scars that the one in the first row can actually see to prove it. So, our story begins when evil cat one is getting ready to perform one of the most common uh attack, the one that actually hits everything that has a login exposed to the internet. In fact, in less than 24 hours after putting a system online, it will get uh

it by a brute force attack. I personally saw a machine being targeted only seven minutes after being put online. For those who might not know the difference between a brute force and a password spray, a brute force is when you have you go you take one username and you go through a long list of passwords. And a password spray kind of works in reverse where you have a very targeted list of passwords and you pick one passwords and you try it against all of the username. It has several advantages. Uh it's slightly less noisy, but now any good CM would detect that anyway. But the main advantage is you can control um the speed at which you do

your your you test the passwords and there's less chance to actually lock the password out.

Uh the more advanced attackers that are targeting specific corporation will use uh targeted username and password when they do password spraying. uh they will use various tools to gather the valid username such as public data breaches uh links on your website and some tooling. In our case here, evil cat one used a LinkedIn scraper. This is a method that is used a lot by our red teamer friends. Um the list of password is also targeted for each company that they will target. So for example here they will use the name of the company maybe the product they are building cities where they have offices and to some sometimes um sports team that are very famous in those city.

So the first password that that they try here is Kirk and Yolo Corp. Bang. And it doesn't work. And then they try warf and summer 2025. Bang. And they have a matching username and password. Now they're going to target um coolse and the first one is Chewarka and Kulsek one. The second one is Boba Fetch and welcome one two three bang and they have a match. Of course, this is a very simplistic view. In a real attack, they would have gone with the same password against all of the username until they have a match. Now, now armed with a valid credentials for both organization, evil cat one found an exposed RDP server. when he tries to connect to the RDP server of

Yolo Cororp, this is what they see. >> Yes. So, by the sound I just heard, I think most of you here can already know what's going to happen to our little golden retrievers. When evil cat one target wh I'm going a bit too fast, but when targets cool, the prompt is slightly different. They get prompted for a one-time password. This is also called multiffactor authentication or MFA for short. So now they need to provide the password that change every minute. According to Microsoft, MFA can reduce the risk of identity compromises by as much as 99.9% over password alone. Let me repeat that because it's pretty important. MFA can reduce the risk of identity compromises by as much as 99.9%

over password alone. We'll let that sink in for a second while I subtly drink water. Okay, now I know that MFA is not bulletproof. You don't need to come see me and say, "Hey, Matt, I can bypass MFA." Yeah, I know it's possible, but it's still a lot a lot a lot better than not using it. And when I hear someone tell someone else, don't use MFA. It can be bypassed. My hair become grayer. So don't stop me to tell me that because my hair are gray enough as they are. Let's continue our story. Because cool sec has a great CM, they also get alerts. They get alerts for the password spraying, but that's the type of alerts

that you get a 100 times per day. So they probably didn't do much with that. It's more like informational. But then they get something more interesting. First connection, first successful connection from an unknown IP. Now probably it's time to start kicking in your instant response. This is not an incident response talk, but if you're interested, I've got another talk about instant response and open source playbook that I recommend you check on my GitHub. And then finally they would get multiple failed MFA when evilcat one tries to guess the MFA password. And if you haven't started your instance response in the previous step now you should really really uh do it. We talked about a few compliance um

standards and the first one was PCI. For the longest time, uh, PCI recommendations for password were as follow. Seven characters. Yes, Randy, it's pretty funny. Uh, they you need to change your password every 90 days. And you need to have some complexity, uppercase, lowercase digits, and special characters. This is pretty much the phase that I did when I read that. And I don't know if you're thinking the same thing that I was thinking, but anyone here wants to tra take a wild guess at how long it takes to crack a seven character password? >> According to Google, it's seven minutes, but seconds minute. It's probably faster today than in 2023 when I made the search for that. Let's get back to PCI.

This is what it was. But let's be honest, in 2022, they actually changed their recommendation. Anyone wants to tell me what's the new recommendation for password length now from PCI? >> Wow, lots of QSA in this room. Awesome. Yes, 12 characters. But they still require you to change your password every 90 days and have some complexity. Now, let's check um cracking table. And again, there's probably a newer version of this, but the important is not the actual number. It's more like the range uh that we that we're looking for here. Uh so if we zoom in a little bit and we check at 12 characters with the complexity requirement, we are at 3,000 years. Not bad. Not bad. But this is

without accounting for human predictability because passwords like welcome one two three bang or summer 2025 bang bang have 12 characters and they are cracked in matter of minutes if not seconds as somebody mentioned before enters GDPR here we're recommending or they are recommending eight characters avoid dictionary words you should use passphrase instead of passwords and same type of complexity of uppercase lowerase digits and symbols. Now here there's one word that really attracted my attention and it's the word avoid. Why are they using the word avoid? And if we start thinking about it, the answer is kind of easy. It's impossible to prove to an auditor that you do not have every single word as a password in

your password database. In fact, the only way you could do that is probably give them all of your ashes for them to crack. And I don't know about you, but I don't know many companies or any companies for that matter that would actually just end off their ashes to an auditing company. And I'm really sorry if you work for one of the big four, but that's the truth. And passphrase here is just when you stitch multiple words together to make a longer password. So we we talked about that roughly, but yeah, eight characters. It's between a few minutes to a few hours uh to crack. Now let's look at Nest 863b. Here they are very different from the

other ones. We are asking for 15 character long passwords, never expire and no complexity. Actually, NIST claims that password complexity is bad and it entices human to use very predictable endings or just increment the digit at the end of your password every time you change your password, which is pretty interesting. When I heard about this and I heard the never expire, I was like, "Wow, wow weewa." I like, "Very nice." Like, how cool could it be to never have to change your password again for your corporate laptop? So, I went on um on a mission to make this happen where I was working. If we're going back to our trusty crack table, 15 characters, as long as you

have some uppercase, lowerase mixed, we're talking about millions of years to crack. I think now we're getting somewhere. Let's continue our story. And this is Evil Cat 2, the post intrusion specialist. And we can see it's a shady character just by the way it look at us. They are the Yeah, that's what they said that uh it got their pause on a backup file containing ntds. file. Those of you who might not be familiar, NTDS.dit is the file that contains all of the password ashes in active directory. For cracking password, you would typically need two files. A password file, in our case here, ntds.dit, D and a second file containing lots of words. We call that a word list or a

dictionary. One of the most famous dictionary out there is the file called rocku.txt um which is very easy to find with a Google search. Now it's time to crack the passwords that we have. And of course, evil cat will not go as low as use John the Ripper to crack. They really want Ash cat. Um, so let's break down the commands that we have here on screen. The M100 is the type of passwords that we are targeting. 10,00 NLM ash, which is normal because we are talking about NTDS. Uh, then we have the the ashes themselves, our dictionary. And finally, TAC R means that we are going to use rules. And sorry I forgot about the the

A Z. This is password attack. It is one of the two mode that use rules. Uh the dive rule is a rule that is included with the Ashcat bundle. It is a very efficient rule. Uh but there's plenty of them and we're going to talk about that a little bit later. But rules are ways that the words in the word list are mixed together. uh suffix, prefix, stitch the word together, capitalize some letters, make some substitution. Uh there's also the prince mode that is pretty efficient. Uh and prince stands for probability infinite chained element. It was created to crack stronger ashes. Typically, when you crack passwords for the very first time in an organization, you might get as much as 50% of their

password within 24 hours. And if you keep cracking for like a week, you might reach 80%. And I can guarantee you that in those numbers, there are some very interesting accounts that you will uncover. Now, we're going to play a little game. I will show you two passwords and you'll tell me which password is the strongest. So we'll start with our friends at uh YOLOp. So first password, welcome 2025. Bang. Second password. Password password. Bang. Who thinks the first password is the best? Nobody. Second password 17 characters. Who thinks it's stronger than the first one? There's a lot of people who haven't raised their hand, so you didn't fall fall into the little trap. But yeah,

officially the first one is 3,000 years and the second one would be 7 trillion years. But in fact, I think lots of you already knew that, but it's my Thai friends who are right. Same same, but different. Both of these passwords are extremely common words. They use very uh common substitution and suffix. So there would be both be cracked in minutes if not seconds because all of those patterns are already in all of the cracking tools out there. Now we're going to play the same game but will with cool sec passwords. You don't need to count the characters. Both passwords have 23 characters. So just focus on the passwords themselves. The first one is backick the empire's barks

back thick. And the second one is patience young padawan. So who thinks the first password is stronger? Okay, maybe like onethird of the room. Who thinks the second password is the strongest? Another third of the room. So I guess one third who thinks they're the same. Oh, okay. Some some people don't want to play, but okay. Uh so this is longer than our trusty time crack table would uh would show us. So we need to go to another tool here. We're going to password.com and according to them the first password would take 161 million year to crack and the other one a mare 29 million years. But if we go to security.org or that also have a cracking tool. They both get

to three September dissillion years. But again, I think it's my Thai friends who are right. Same same but different, but still the same. Both password would take a lot longer than anyone can or will invest in cracking those passwords. So now it's time to see how evil cat 2 fared against the two password uh file that they got their paws on. Sorry I did forgot to click. Um so first one not surprisingly they got 80% of the password but at cool roughly 1%. So we will see in the rest of the story what Coolsec did uh exactly to get such a good result. So first of all they um they did something that not a lot of people do.

I've seen that being done in some financial institution in the past uh but maybe not to the extent that we're going to discuss here and uh I actually was talking with one of our customer uh not long ago and they're doing almost exactly what I'm going to present here. So I'm kind of very happy that this methodology is picking up in the real world as well or in in more organization now. Um so they went with the NIST recommendation of 15 characters never change or the password never expired. But they here's the twist. They will crack their own password every on a weekly basis. And a password crack equals a password change. So how do you actually do that in the

real world? Because it's it's nice to say it, but let's see let's see the steps to get there. So first of all, you need to create a service account. Then you're going to give the rights replicate directory change all to that account and that will allow you to perform what is called a DC sync. So pulling all of the information from the domain controller to a non-domain controller machine. You need to create a GPO that will reflect what you want. 15 character password, no complexity, never expires. This is a key part. Inform your user of what is coming. If you just do that, people will be lost and they won't understand what you're doing. After

that, you need to apply that GPO. So it takes effect and then you need to force change your passwords. Now please do not go to work Monday and do this again. Inform your user and don't do that in one go. Your Lesk will hate you for the rest of your life. Right? It go by wave, go by OU. Uh be smart about this. But really consider doing that in your organization just not Monday. Okay. Now we've set up our our policy. Our user have changed their user. Now it's time to have some fun. So first of all um we going to use in okay what I've seen in many corporation is the security team would ask the domain admins hey can I

have the NTDS.dit and then the domain admin goes on the DC pulls NTDS give it to security. When you do that on a weekly basis, maybe, just maybe, your domain admin will be a bit bored. So, here's a tool that will help you get the the password ash on your own and automate everything. So, here's the tool. It's called DS internals. It's a tool made by Michael Graphneter. It's been around for a while. And funny story, when I created this deck the first time, Michael helped me and made sure that everything was right. And uh Michael was hired by Spectre Ops 3 weeks ago. We went uh through the slide and say, "Hey, I updated my tools." So this

version of the deck actually has the latest and greatest version of DS internals. Now, because I'm not a Windows person and even less of a PowerShell person, I remind everyone that is like me that you need to import the module if you want it to work. Otherwise, you'll just be wondering why it's not working. very basic but very important. Now we're going to create a variable called cred and we're going to call the method called get credential that will pop up a screen on our um yeah a screen on our terminal and we or guey and we can enter the username and password that we created in the previous step. Now that we've set up the the tool, it's

time to use it. So here we will use the method get ad replicate account and we're going to target one of our DC. We're going to supply the credential that we capture in the previous step. We're going to focus only on the accounts that are enables because there's no t there's no point in wasting times on accounts that are disabled and we're going to format that in a file that Ashcat can actually read and use to crack. Now a cool little twist here. We're going to run the same command a second time, but instead of formatting the output, we're going to check password quality on them with all of the passwords that we cracked. Of course,

the first week you won't have any password that you've cracked. So, you can skip this, but as you go, your list of cracked password will go bigger and bigger and bigger, and this will save time because you'll be able to remediate things a lot faster. Now, it's again time for you to wake up and play a little game. I want to know how many here have only one account to rule them all. Nobody wants to admit it. It's okay. Uh who have two accounts? One user account and one let's say administrative account to administr uh administer servers. Quite a few. Okay. Who here has three accounts? That would be one user, one admin and one domain admin accounts that

can only work connect to domain uh controllers. That is the preferred way, the way Microsoft wants to do it. Uh if you want to go that route, I highly recommend using bloodown to make sure that what you intend to do is what is actually happening in your environment. Um, why I'm asking this is that one of the reason why we have all of these users is that we do not want them to have the same password. Right? If you're using the same password for your user and your domain admin account, uh, if your user account gets compromised, they have the key to your domain admin account as well. So, one thing that you should do

is when you pull the ashes, make sure that there's no duplicate ash in your password files. If a same person is using the same Ash, you should inform them, force them to change their passwords. If two different human being have the same Ash, well, there's one of two things. Either they have a password that is guessable even if you're didn't manage to crack it or your process is broken. Maybe your uh Elesk is resetting the same password every time or creating all of the new accounts with the same password. But there's something broken in your process. Let's continue. Now we've pulled the password. It's time to crack them. Yay. For those who've been following since

the beginning, you might recognize the very first command. It is the same command that evil cat 2 used against the organization before. So, if you remember when I did my intro, I said I like uh this one thing. I think I didn't say it actually, but uh I like to use adversary tools to make their life miserable. And this is the example. Um, so the second line here, you see that it's almost the same as the first one. The only difference is the rules. So there are hundreds of rules around. I think that even NSA has published their Ashcat rules. So you can play with those rules and you can run run as many rules as you

want one after the other and you might get some very interesting results. Some rules might work better in your environment than in your peers's environment. It's really depending on the on your user base. The third command is uh the good old brute force where we start we try every single character. We go from one and we just increase until you stop it. Once you're done cracking or brute forcing in this case, it's time to copy the ashcat.put putt file which contain all of the ashes that you've cracked so far into the weak ash txt. The reason why we do this is because most of the time you will not pull the passwords from the same machine that you

will crack them. So you want to be able to use the weak password uh with the DS internal module to make sure that you don't have any cracked password already. Now there's one last step. We've found weak password. So we're going to now pull information about those user from our active directory. Uh we will compile a list of people that we've changed their password and we will force them to change their password again. And the reason why we keep a list is that if it's maybe like the third time in three weeks that you ask someone to change their password, maybe just forcing them a fourth time might not do the trick. So now it's time to educate

your user on how to create strong password and not just increase the digit at the end. So you might be asking, Matt, that's pretty cool, but how do we actually create a strong password? In my opinion, there is two different scenario. And yes, I'm a big Deadpool fan and I wanted to make sure that it's there at least once in my presentation. Scenario one, you never have to type your password. In this case, you should go as high as the uh portal that you're using allows. H otherwise, like in active directory, you can you can aim for 64 characters. you store that in a password manager and you never have to type it again. You never

have to remember it. It will just fill automatically when you need it. But if you need to type your password, so for your password manager for example or your laptop, then I would recommend something that I called dressing the password. So that gives you a password that looks a little bit like this. Pound pound dollar. I had a bad feeling about this. Dollar dollar pound. This is a 37 character password that is very easy to type, very easy to remember, and kind of long to crack according to our website. So, I have no idea what the Septan Dilioner actually is, but it does sound extremely long and I'm not sure that even Deadpool would survive this.

Yes sorry bro. Now an additional tip for those who have a very acute ear. You might have noticed that English is not my first language. Uh so you can use your mother tongue to create your password. Here we have the famous Yoda's quote fear leads to anger but in French. So we have pound dollar la dollar pound. It would take roughly 900 dicilion years to crack these passwords. And what's interesting about this is that thank you I already have some is that um neither the word men or kalai are in the rock dictionary. And that brought me to ask myself a question. How many of those characters are actually in Rocku? Those characters are actually in Rocku. Rocku has over 14

million passwords and out of them 800 have this little C thing. 500 more or less have the the E there with the accent which is super prevalent in French. So was kind of uh I was very curious why it's less present than the C. But then I realized that the C is also used in Portuguese a lot. So that might explain why. The S with the reverse hat there that is uh in the Slovak languages is there roughly 65 time. The German ets like the double S is there about 70 times and the finally the kind of reverse bang from the Spanish language is there only 90 times and that's the one that surprised me the most. Like

typically you'd see the exclamation point is extremely popular. So I was thinking that Spanish people would use that symbol a lot more. So to give you an order of magnitude, we said that the the one that has the most hit is the first one with 800. And to compare that with the letter A, the letter A is present in 9.5 million passwords out of 14 million. So yeah, Matt, this is pretty cool, but we're in 2025. We're moving to the cloud. So what about intra ID? Well, I'm glad you asked. In active in intra ID, there's something called password protection. This is a list uh maintain there. Sorry, Microsoft is maintaining some words that that they ban something

like things like welcome, summer, winter, uh all of these. Well, yeah, I said welcome. uh all of these very easy words, but Microsoft doesn't know anything about your specific corporation. So, if people in your company are using your company name, you should put it in there. Uh I talked about the sports team. So, sometimes when you crack, you'll find like I don't know, I'm from Montreal, so maybe like Montreal Canadian could be very popular uh password where I'm from. So, I could put that here. Like, so the goal here is every time you crack a password and you see that a word is used over and over again, just stick it in there and your user won't be able

to use it anymore. Okay, but we can get the ash ashes out of intro ID, right? Ah thanks Donald. As a Canadian, I never thought I'd say that. And especially not especially not this year. Um now here you have a tool we have a tool called entra uh sorry AAD internals that was built by neestory aka Dr. Asure AD and again for those who have a very good sense of observation you might be like hm DS internal AAD internals looks very very similar and you would be 100% right netori name this tool after Michael's tool now I need to give you a little warning before we continue if you are already pulling your ashes from active directory

do not use this method this is more complic complicated. It's you get you're going to get the exact same results anyway. You're just going to make your life harder. So, let's see what you actually need to pull information out of active directory and neesto will guide us through the steps that we need. So first of all obviously you need to have the ashes in your intro ID and then you will need credentials for an application that has the Windows legacy credential rights. As of today there is only one application that we know have these rights and it's the Azure AD domain services sync or AADSS. And finally, you will need the encryption certificate that lives on

your Entra ID domain controllers or controller. With those three things, you can now install module AAD internal. Do not forget to import the module if you want to use it. uh and then you can actually use the module and use uh get a a int user nt aash and provide the client password the client ID and as we mentioned the encryption certificate that you've pulled from the intra ID domain controller now we're already almost at the end of our story but I want to give shoutouts to the people who created the tools that were demonstrated in this talk so first of all of course Michael Graphnitter with DS internal, Dr. Asia AD for AAD internals, the awesome folks that

created Ashcat, and they actually released a newer version just last Friday before Black Hat. Um, but a special shout out to a guy named Obvious Malware that presented back in 2022 at the Red Siege Wednesday offensive. um and he's the one who kind of reminded me about the DS internals tool and that really uh speed up all of our uh program. And finally, there's there was a talk uh at the Red Team Village from a guy named Travis Palmer. The talk was password cracking beyond 15 characters under $500. Now, I would like to leave you with one quote. Do you want to mitigate against auditor or attackers? And I think this kind of res summarized this talk very well. If

you blindly follow the recommendations of the different standards, it doesn't make you any more secure. On the other end, if you use them intelligently uh and you train your user properly, those same recommendation can actually help you increase your security posture. And as you saw, it can actually be quite fun to implement. So if you want to continue the conversation, I think we have times for question. Uh this is the Spectre Ops public slack. I'm there all the time. I'm on Twitter at ScoobyMTL. This is my LinkedIn if you want to connect. I will everything is open at least until the end of the week. Uh yes, question. >> Great talk. >> Thank you. >> Welcome. Uh so is it Urban I have a

question to follow. Is it urban myth or true that it is urban myth or true that it is easier to crack a password when the user puts a bang at the end of it? And then the followup is if they insist on putting a bang on the end of their password based on your slide, should we be encouraging them to use the Spanish bang instead? >> H if they have the Spanish Yeah. Uh I'll answer the last one first. If they have the Spanish uh Spanish keyboard installed, probably yes. Uh I I think I I'm not an expert on that, but I think that the bang at the end of a password don't change anything. it just makes you

compliant to the password policy because this is the first thing that any cracking tool will actually try will just add that symbol at the end right so and it also most of the password that are common so on the English keyboard will be tried anyway uh so that's why I recommend putting at least two characters at the beginning and at the end and not just one character at the end any other questions guy with the hat

I can ask my question first. So passwordless

solution like Microsoft want to push it down. So the question was what do I think about the passwordless uh solutions? I think I I brushed that at the beginning like in the introduction but I really encourage everyone who can go passwordless to actually go passwordless. It's makes your life a lot easier. It's hard to crack a password when there's no password. >> Yes. So, for the uh enter ID password prevention list, um do you recommend just dumping like the Rocku text in there or like I mean what's the practical limits there? Right. >> Yeah, I that's a great question. Uh I know I do not recommend dumping the whole Rocku there. Uh and in Roue

there's a lot of lines that are broken if you look at it. Uh so you can kind of clean it up. But um no, there's a lot of password there that have little utility. Um, but I I think that if you crack your password regularly, you'll see what your user are using. It's going to be obvious which words you need to add to that list. And and remember that Microsoft is maintaining their own list. So, there's already uh a large amount, but it's it's I think it's especially useful if you have non-English speakers, like if you have offices somewhere else than a US, Canada, an Englishspeaking country, you might find words in other languages that

make their way in your password very very often as well. I think uh there was one more question there from uh from someone I think I know. >> That was an excellent talk. Thank you very much. Thank you. >> Um on the never expiring password, I think that just makes everybody who's ever administered passwords just super nervous at the core of their being. Um is there still some risk that you think um and what I'm thinking of is like not that people have crackable passwords, but they reuse their passwords across multiple sites and quite often those passwords get dumped from some other site. Um so is there is there value still in rotating passwords even like

every 90 days? I wouldn't but um I don't think every 90 days if if you most of the time when I've seen this implemented the the thing that was preventing people from going to never expire was compliance and some auditor that did not really understood uh the counter measure in place and that's why I also recommend to crack your own password uh but that's not what you're asking um if I really had to change the password I think I would go for at least one year so that people can use their password for a year and then select a real good passwords and not just increment uh the digit at the end or just change something trivial like they

really have like they don't have a year to think about it but but you know what I mean like they know that they're going to be stuck with that password for a year so it's kind of worth investing sometimes to create a new and good password >> that seems like a good balance and then followup would you consume lists of leaked passwords like the big dump sets and do you use that also Yes. Yes. Um, yeah, if you want to go like a little bit, you you can the the the point here of the talk is also to have fun doing that. So, changing your password dictionary is a great way to do that. Like ma mix and have fun. One week

you can crack with the rock, another week with something else if there's a new leak. Yes. Yes. Totally 100%. So another question here in front.

>> So when it comes to the compliance part though, are you using the weekly crack that you do as a compensating control to get around the 90-day requirement? Right? Because you're going to have to prove out that you're doing something else. >> Yes. Uh exactly. So cracking the password, you'll see that some password will change over time. uh but then if if it's uncrackable uh and it's always the balance between who's auditing you right and then you need to convince them but once they're convinced and when you show them that you really have strong compensating measure typically it works but yeah there's some people that are more stubborn than other and and I say people and not even companies right

sometimes it's really one like the person that that they sent you this time that won't accept it but if it was accepted the year before typically you have ground to keep to keep it like I've never seen a company having to revert back once it was accepted. >> Thank you. >> You're welcome.

>> Uh awesome talk. >> Thank you. >> Yeah. I I was going to ask uh how do you what do you think about the the challenge of let's say companies where that there's the whole right usability versus security. So if they have to use passwords still um how do how do you convince a company to increase to a password length that the typical user is not going to want to quit their job and pull their hair out every time they type their password in? >> Yeah. Yeah. Yeah, it's a good question. I I think that the advantages of not having to change their password all the time makes a lot of people very happy to check to to have a

longer password if especially if you take the time to give um example of passwords or tips on how to create longer password because it can be easy to create a long password that is easy to remember. Um so I think that this draw like this If you if you just go to 15 characters or 16 characters or whatever and you force them to change their password every 90 days, they will be lots of user won't won't be happy. But I think that the the fact that they don't need to change it change change the game altogether. And it's a it's a nice way just kind of to Rendy's point, it's a nice um it's a

nice time to remind them to not use the same password everywhere. and that they should use strong password password manager as well. Uh this works very well in companies where pe where the company is providing a free password manager uh to their employees. >> One more. >> Yes. Um is is there any particular um easy to implement uh solution for implementing password block list that spans not just you know obviously Windows Azure so but that would easily span other applications to make it manageable. Um, I know there's a solution for um for active directory, but the lots of people don't you need to put like a DLL in your um domain controller that will look at

the passwords that are typed and block them if they have a list that you maintain. So, it's kind of the same functionality, but for uh domain controller, there's an open source version and there's a commercial version of that tool that works for Active Directory. I don't know if you have something that works for like everything like or if you have um SSO solutions that are different. I'm not familiar with that. Any other question? Well, thank you very much. I hope that you improve. Thank you.

[Music] Woohoo! [Music] Woohoo! [Music] Heat. Heat. [Music] [Music]

Everybody [Music]

home. [Music]

Down. [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. [Music]

Heat. Heat. [Music] Heat.

[Music]

[Music]

[Music]

[Music] Heat. Heat. [Music]

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

[Music] Heat. Heat.

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

Heat.

[Music] Can everyone hear me? Yeah. Okay, I'm definitely on. I can hear myself. Welcome to the last uh talk for Passwords Con 2025 at Bsides. Uh it's really been a um a great uh couple of days that we've had some awesome talks. I'm sure we've learned a lot those of us that have come for uh some of the other talks as well and uh on behalf of myself and P of course who could not be here. We want to thank everybody who attended and of course the speakers as well. not forgetting to thank our diamond sponsors Adobe and iikido and our gold sponsors uh formal and run zero and then of course as as always mentioned all the

sponsors the volunteers everybody including yourselves who make conferences like this pos possible u we're a community we work together we research together we teach each other and passwords con is just one uh piece of that that great puzzle so yeah thanks very much for attending this this year. So, let's move into password expireies dead. Real world metrics on what rotation actually achieves and a little bit of the thunder was stolen by the previous speaker, but I'm happy about that because he's kind of laid the foundation a bit about where we're going and why we're having this this this talk now as well. Just a little bit about me. Uh so I've been about 21 years in cyber security

primarily pentesting architecture. I've been on team hashcat since I think 2013 somewhere around there. I'm currently the chief technology officer at Bitrack Cyber Security. I'm also on the CF review board at Bites Athens and safety ops for Bites Las Vegas as well as now uh running passwords con. And yes, I have set an undisclosed number of hash rigs on fire in the past. So, um, yeah, on the team, if there was, uh, ever anybody that was setting hash rigs on fire, I I seem to be quite good at doing that. Cool. Then I just included a mandatory cat picture. Those of you who've been following Passwords Con for a number of years will remember we used to have a

mandatory requirement for cat pictures. And, uh, I think it's time we slowly start introducing that again. So I thought let me put that in quickly quickly. But let's jump to the next slide. How many of you recognize these uh what is being said here? Um right so these are quite old right um and at the time uh they came from the PCIDSS something authoritative uh the best practices one was from Microsoft and then there was also um a list one mentioned there as well and they all said the same thing to us they said change your passwords every 30 days expire them that's how you keep things secure that's how you keep your company safe. That's how you stop yourself being

hacked. Okay, most of this came from about 2010, 2011, 2012. Where we are now, did did that work? Did it not work? Well, we can see it didn't work very well because we were not anymore secure. We see some massive leaks that have happened, hacking, breaches are all over the place. So, something was not right about that. And the fact of the matter is it doesn't work. And it never did. Password expiry was not the magic bullet of every 30 days or every 60 days when all our staff and all our clients and all our users change their passwords that suddenly things were going to be miraculously secure. They would pick strong uh candidates that pick ultra

strong uh passwords and everything was going to be fine. In fact, quite the opposite happened. What we in fact did is that we drove the reality of user behavior in the wrong direction. Okay. And the reason for that is because users are very good at finding ways to do the least amount of work they have to do when it comes to choosing a password. Right? If you tell them that they should uh enter 10 characters, they will enter the most basic 10 characters they can. When you tell them it's got to have a number in it, guess where that number is going? At the end. When you tell them it's got to have a special character in

in it, well, it'll be something at and a number. Okay? Usually things like that. So, and it's not because users have malicious reasons for doing that, right? They're busy. They have a job. They got things to do. They want to get things done. And you come and step in the way by telling them to change the password all the time. And so, they will pick what is the easiest thing for them to remember. The same thing applies to when we told users to change them every 30 or 60 days or 90 days. We expire it. They now have to think of something else, right? And remember, whatever company or organization we representing is one thing. They have

maybe a password somewhere else. They have three or four accounts. They have their social media. They have their there's so much that they need to remember and think of. And so this drives them to find ways to do it as easily as possible. It's also why if we consider tools like hashcat for password cracking, how many of the rules were optimized for this and how the hit rate on those rules is so high because users will find a way to introduce a pattern to make it easy because they have to change their their passwords all the time. Patterns when cracking are often based on how uh user behavior is when changing them as well. So we all the rules all

the methodologies that we've seen and there's been some talks during uh passwords con that has covered that kind of topic they've all centered around how users uh will adapt the requirement to change a password. So some examples right we have our base word which is in purple on my screen. I'm not sure how the projector is rendering it, but that's the base uh one that they started with and then as they're getting forced to change it, they're making some quick changes in their mind. Okay, let me add a number. Let me in increment the number. Can't increment the number. Okay, because you're remembering some of them. So, let me change some of some some of it. So statistically and in all

the years of password cracking that I've been doing and that everyone else I think has been involved in um you will notice that these patterns come along all the time as users have to pick new passwords they will make them uh statistically become some kind of a pattern and it's even more interesting if you have the opportunity and it's not everyone that gets this opportunity to look at a company or a corporate's domain uh passwords over a period of time and by time I mean like four years or five years constantly cracking them when that password expiry was required. You will notice that uh these patterns were creeping in quite quite a lot. So we were a bit responsible for that for

making users change the passwords all the time because they had to think of something they can remember. So the result of that if you look at some statistics and obviously I have renamed uh some of these organizations to use case for obvious reasons. So use case one through four where four is the one that has the longest requirement in between password expiry for the users. Right? So looking at use case one in the banking industry a 30-day password expiry requirement. Back 10 years ago, we were told that's the way to go. It's the safest. There'll be no issues. Look at the next column. Passwords with trivial increments. 60.4% were matching were cracked with simple rules that were just looking at

incrementing things in the password, usually something at the end like a number or a letter. The total crack rate 89%. So, did it actually help anything? No. when when the breach happened, mand mandating password expiry didn't actually make you any more secure than it did the next person or the next one. Right? So going to the next use case uh finance institution 30 days as well 54.9% easy to crack but the rules also primarily being the ones that were um that were users incrementing or appending or doing the usual at June one at uh August 1 and so forth to try and constantly change the password to something that was that that made sense. Um, and a side note here, if you are a

hashcat user, there's a very nice mode you can use in hashcat which will show you which rules are the ones that are cracking um, the majority of the password. So, you can then work back from that and script it to see what the majority of them are. In this case, the trivial increments are the ones I'm calling where it basically just appends things at the end of the password because the user had to quickly pick something new and 91% of them were cracked there. Use case three was a power utility. They had slightly longer 60 days. Okay, bit better but still every two months and that comes very quickly when you're a corporate user and you're working and

life is carrying on. So they would have to change that password as well. 62% there were matching trivial incremental rules. And then the crack rate or the total crack rate being 79%. Now the last one in back to the banking industry again was 120 days plus and the reason I've done this is because um this one kind of m made up of not just one uh or organization but a few in the banking industry where they had at least 120 days. Some of them could have had uh 190 365 and so forth. But notice how things are changing slightly now because the passage with trivial increments is coming down. So stronger passwords are being automatically chosen by the user because

they don't have to change it so quickly. They'll think of something strong, right? I I'll think of something that I I will remember. It's good. It's locked in and it stays there and it's not going to expire in 30 days and force me to use something else. The crack rate there, 70%. So here's something interesting, too. It doesn't necessarily mean it's making the passwords more difficult to crack. Right? What we're saying we're not saying here is that it's a magic it's a magic uh bullet as it were that when you increase password expiry to 90 days and something days or a year suddenly no one's going to be able to crack them. It makes it more difficult

but it's not as uh it's not as um it's not that silver bullet as it were that's going to stop anything being cracked. So what we're saying here is that you can't rely only on password expiry. And I think that that's what's coming across as well. As we continue, you'll see from the other ones. And so if a domain is compromised, your password expiry is meaningless, right? It is. it's meaningless because whether it's been sitting there for a year or it's been sitting there for 30 days if it's not a very strong one or if it's you know the way computational power has has has progressed today when it comes to cracking NTLM they will be cracked so password expiry

cannot be relied on on its own to secure an environment anymore than it used to be what are the other negative side effects Right? It causes people to increase the forgotten password tickets at help desks. Okay. Every 30 days, users change their password. It's now been 3 months. They need to log in. They've been on vacation for two weeks in the Bahamas. There's been a whole lot of alcohol flowing. The brain is not exactly where it should have been. And which which password did I use? Because I've changed them so often. I don't remember which one. Call the help desk. Right. So, it increases that as well. Also, password fatigue gets gets increased which results in insecure practices. I need to

change my password every 30 days. I'm not going to remember it because there's so many of these things and you're remembering the the the last 10 which I had. So, I'm going to start writing them down on little postits and little notes in books. There's a book uh I saw a book on Amazon the other day. It was called a book of passwords where you can write down I mean I don't even know why it's being sold on there. It should it should actually come with like a warning strapped to it. But but anyway, but people do that because they have to change them so often they want it somewhere where they can remember it.

And then like we've shown there's no measurable benefit. All right. If you are breached the fact that the password was changed every 30 days, 60 days, 90 days or or longer has no actual measurable benefit. So why do it? Why force the users to change it so often? create all that uh password fatigue, all that help desk uh increase in workload for them when in actual fact it's not going to help anyway. And so what happened? We have adjusted the approach. NIST has adjusted its approach and said that um I don't know if you can read that uh small text. Well, basically the short of it is what we're saying. There's no actual value to forcing users to change their

passwords to expire them every so often. rather focus on other means of securing that method of authentication. Let the user pick something strong that they remember and that will be there and valid for a long period of time. Microsoft says the same thing. And uh some of you will have noticed if you're uh when you're logging into your your Azure and other platforms and trying to set the policies and you try and make that policy quite short, it actually brings up a little message saying, you know, this is not really recommended. do you want to do this? You're creating more issues than you're going to solve. So, thankfully, we've adapted and realized that this is a problem and so

we need to do something about it. But then the question is, okay, so we're going to allow passwords to be valid for a very long period of time, but that how does that help us? What can we do? Because we may still be breached. There's still an issue. Okay. Well, there's a few things we can do and we can work on. time to crack scoring is an interesting one and some of this I think was covered in the previous uh previous uh talk as well just before this one. So crack the the passwords in the domain and I think about five or five years ago or somewhere along the line there was a um a passwords con in Cambridge and this

came to the four as well. It was why not crack the passwords in your company. There's no law against that. There shouldn't be a law against that if you're within the organization and you've got ownership and you you've got the permission to to do it. So crack them and use the time to crack to understand which are the weak ones and maybe focus on expiring those instead of everybody. Okay. Event or risk based resets. Okay. So if your sock or your seam or whatever is doing your threat analysis, maybe you have a a dark web feed that's telling you that credentials have been leaked. that can trigger an expiry and a reset. Time is irrelevant there. As soon as

that risk comes in, you should rather I seem to be having the same issue that somebody else had. So, let's just reset this quickly. Okay, let's see if it comes back. And we wait and we hope. And it's back. Okay. Um, so yeah, so trigger the expiry or the reset on an event. And I'm using expiry and reset together now because we don't actually want to expire the password unless there's an actual reason to do so. Credential entropy monitoring is an interesting one. Again, using tools like hashcat, look at how much entropy is in the the the passwords that are being chosen even by one person. So you can build some interesting tools yourself here. Um,

pick your favorite uh DB, MySQL, Postgre, whatever you want to use. Start putting the data in there and look at things like entropy per user is an interesting one, right? So, five users in the organization, very strong password, no issues. You got another user that it keeps showing up in breaches. They keep resetting it. It keeps having issues. They lock themselves out. Gets changed again. And the entropy is not that great when they are setting new passwords. educate them and then force a reset so that you get something stronger and then of course multiffactor authentication is the one that everybody NIST Microsoft etc are mandating on top of it all uh to ensure that if that password is breached

um that it's not a an issue for the organization now one thing to note with MFA is that unfortunately we seem to like these uh these one solution solves everything everything thing because we first said expire passwords and then everyone's happy. That's going to stop us being breached. We realized that doesn't work. Put on MFA. So, we did that and then sat back and said thought, well, okay, that's going to fix everything. It's not okay. MFA still needs work. The amount of organizations I've seen where the fallback for when MFA is not available is just nothing. Oh, you didn't have your phone, your authenticator, so we'll let you through. Because when we don't then the business

comes down and says you're you know securities in interfering with uh with uh the corporate we're losing funds just turn this thing off and what happens somebody goes and turns off MFA and you're back to square one again or failing MFA failing for something less secure like email right if you think somebody's breached your environment there's a very good chance they're reading people's emails so falling back to sending one-time pins or MFAs of some kind to an email that's a bad idea as well and so is the please press the button on the phone to accept this login because fishing and fishing are very good at targeting that kind of thing. So there's various ways of of implementing

strong MFA uh authenticating the device, checking is the device the one the user had and we're not going to go into detail about that now but what what the point is here is put MFA on top but make sure it's implemented properly and securely and robust and then you don't have to worry about pass password expiry because it's that you don't need that value from there either. Hashcat is your friend, right? And and I know there's other uh password crackers out there, but since I'm on team hashcat, hashcat. Um if you need help on how to use hashcat, they have a discord. I don't know how many people know that there's a discord server where not only

there's a lot of helpful people, but the people who actually write the tool, work the tool, build on the tool, use it for cracking are on team hashcat. They're there to help you use it in a way in your environment that gives the benefit that we've seen to do this risk based approach of expiring passwords to audit them to understand what's going on in the environment. Hashgcad version 7 like we announced let you cater for custom setups a lot easier. So we tend to focus on active directory a lot but there's many other applications that could be expiring passwords and don't need to stop doing that there. But then you also want to audit those. Well, now you can because

if they're using an algorithm that wasn't common, you can now use the Python bridge in Hashcat to ensure that it can crack those those those passwords as well. Um, and then use it with automated modes. Hashcat can be scripted very well. Right, you've got modes such as dash uh capo which will um which is optimized kernels when tracking below a certain uh uh keyword length or candidate length. Right? If you know your users are not setting passwords of 22 characters, they're sitting somewhere around 13 or 14, optimize it so that it cracks faster. And the dash uh W which tweaks the workload. So use all of these, put them together so that you get the value out of that.

That is the time that I have. Uh and once again, I just want to say thank you to everybody for attending uh passwords con this year. Um, as I mentioned in the beginning, the speakers, the sponsors, everybody. Um, take what you've learned now for the rest of the year until we come back here again for Bides. And you know, we're always everybody's looking for speakers. Do some interesting research, do something that build on what has been said here. Come back next year and and really show us what what you've done. So, don't forget to submit uh to the CFP as well. The next Passwords Con is December 1 to3 in Prague uh in the Czech Republic and

information on that will be released soon at Passwords Con but of course it will be here again next year at Bsides as well. So I have done enough speaking and uh yeah thanks everybody for attending Passwords Con and uh I hope you have enjoyed the rest of the day. [Applause] We are completely out of time for Q&A. Um, so you're welcome to speak to me afterwards if you want. Uh, on the side ask any questions. I'll gladly answer them for you. [Music] Hey. [Music]

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