Listen to the following security and product experts share their insights in the webinar:

• Tom Field, Senior Vice President of Editorial with Information Security Media Group
• Jasson Casey, Chief Technology Officer at Beyond Identity
• Roger Grimes, Data-Driven Defense Evangelist with KnowBe4

Transcript

Tom Field

Hi there. I'm Tom Field. I'm senior vice president of editorial with Information Security Media Group. Very pleased to welcome you to today's session entitled, "Not All MFAs are Created Equal, Some MFAs are More Equal than Others." Your presenters are Jasson Casey, chief technology officer with Beyond Identity is joined by Roger Grimes, data-driven defense evangelist with KnowBe4. Now, before I turn this over to Jasson and Roger, let me give you a little background on what they're going to talk about with you today. 

With the explosion of ransomware and stampede of account takeover attacks, MFA has become the go-to solution and a must-have if you want to renew your cyber insurance policy. But many MFA solutions rely on passwords and other phishable factors that are easily bypassed by hackers. In this session, Roger and Jasson will discuss and demonstrate how adversaries, from financially motivated actors to state-sponsored attackers, can compromise systems protected by the legacy-style MFA. 

Topics include, what are phishable factors and how can they be exploited? Is this just rhetorical or are these attacks happening in the wild? What requirements will high-trust MFA solutions need to address? And what are critical components of a modern MFA solution? Little bit of background on my organization, Information Security Media Group. We are a 16-year-old global education and intelligence firm. 

Our headquarters is in Princeton, New Jersey, in the U.S. You might know us by one or more of our 34 media properties. These include BankInfoSecurity, GovInfoSecurity, and DataBreachToday. In all, we reach an audience of over one million security leaders around the world, and we give them a daily diet of news, analysis, research, events and educational programs just like this one. 

A few housekeeping notes, if you have any questions for Jasson or Roger during the course of this session, you can submit them anytime by the chat window on your screen. We likely won't get to every question today, but for those that we don't answer in the course of this session, we will get responses back to you via email. Take down this email address you see on your screen because if you should encounter any technical issues while viewing today's webinar, you want to write to webinar@ismg.io. 

We do have support staff standing by to help. Also a reminder, today's webinar is copyrighted material. That means it's meant for today's session and individual study purposes only. If you'd like to use any of the information presented today or if you're looking for customized training materials, please, contact us. 

Delighted to introduce our sponsor today, Beyond Identity. Headquartered in New York City, Beyond Identity was founded by industry legends, Jim Clark and Tom Jermoluk to eliminate passwords and radically change the way the world logs in without requiring organizations to radically change their technology stack or processes. Funded by leading investors, including Koch Disruptive Technologies and New Enterprise Associates, Beyond Identity's mission is to empower the next generation, secure digital business by replacing passwords with fundamentally secure X.509-based certificates. 

This patents-pending approach creates an extended chain of trust that includes user and device identity and a real-time snapshot of the device's security posture for adaptive risk-based authentication and authorization. Beyond Identity's cloud-native solution enables customers to increase business velocity, implement new business models, reduce operating costs, and achieve complete passwordless identity management. 

To learn more, please, visit beyondidentity.com. Now let's meet our speakers. Jasson Casey has served as CTO of SecurityScorecard, VP of engineering at IronNet Cybersecurity, founder and executive director of Flowgrammable, as well as Compiled Networks, VP of VoIP Product Development at CenturyTel among other technical and executive roles. 

He is, of course, now chief technology officer with Beyond Identity. Roger Grimes, KnowBe4's data-driven defense evangelist is a 30-year computer security consultant, instructor, holder of dozens of computer certifications, and an award-winning author of more than 13 books and over 1,000 articles on computer security. He's worked at some of the largest computer security companies, including Foundstone, McAfee, and Microsoft. 

With that, going to turn you over now. Jasson Casey and Roger Grimes, gentlemen, virtual stage is yours. 

Roger Grimes

Glad to be here. 

Jasson Casey

Thanks for having us. 

Roger

I got to say, I love this George Orwell reference you have here. 

Jasson

Trying to make it interesting in the beginning, right? Keep people's interest. 

Roger

And so this is me again. You know, it's hard to believe I've been doing computer security 34 years, earned all of these gray hairs. But as part of that, I was a professional penetration tester. I was hired by companies to legally break into their company. And let me say in 20 years of breaking into companies, I broke into every company I was hired to break into in an hour or less, except for one that took me three to five hours because I was back there the second time. 

But as part of it, I also have implemented hundreds and hundreds of MFA solutions. You know, way back in the day, it was RSA SecurID tokens. I think that was probably the first MFA that most of us came across and then a lot of smart cards, and then it moved into fingerprint scanners and USB keys and that sort of stuff. I was hired to break into lots of MFA solutions. 

And a lot of times, it was like trying to fool biometric scanners or trying to find security flaws in code. And let me say, in every single case that I was hired to try to hack into MFA, I was able to. And I don't think I'm special, I don't think I'm some uber-hacker, you know, from a scale of one to 10 on hacking, I'm probably just a five or a six or something like that. 

You know, but once you know how to pen test and you know what to look for and that sort of stuff, it's not that hard to find flaws. But using that experience and knowing that multi-factor authentication was taking over, it led me to writing a book about multi-factor authentication. If you could, Jasson, go to the next slide there? 

There are some of my books, but the one that's most relevant for this talk is I wrote "Hacking Multi-factor Authentication" for Wiley. And in that book, I cover, you know, almost every type of MFA that's possible. And I talk about all the ways that you can hack various types of MFA solutions. I give lots of examples. 

I give lots of recommendations of how to secure different solutions. And in the process of writing that book, I reviewed like 130, 140 different MFA solutions. And now I'm probably up to 170, 180. And I had lots of vendors, MFA vendors when they heard I was doing this or heard me speak that would say, "Hey, you think you can hack my solution?" 

And they would send it to me and I would hack it. And then sometimes they would go back and forth and I would hack it many, many different times. And each time they'd give me back a stronger version, I'd hack that version or a different way. And then occasionally, sometimes they would get them so secure that I couldn't hack them. But through that process, I learned a lot, ended up writing a book and some other articles. If you could, go to the next slide. 

And that's what kind of gives me, you know, some of my thinking today that I'm going to share. So, you know, worked on dozens and dozens of MFA and MFA hacking projects over the last 20 years. I wrote that book for Wiley "Hacking Multi-factor Authentication," which covers, you know, over 50 ways to hack various types. 

In one of the chapters, I take what I think is one of my most favorite MFA solutions, or one of the more secure ones, and then I try to think about how would I hack it and I share that. And then I even go on to another chapter and talk about how would you make one that's unhackable? And I try to go through that particular...and matter of fact, I try to secure remote online voting. I try to imagine a day when we can all vote from the safety of our home and how would you make that safe. 

So I really try to take the, you know, people back and forth on how to look at MFA, how to hack and, you know, how it can't be hacked, that sort of stuff. Ended up creating a webinar called, "Many Ways to Hack MFA." It was actually created... I wrote a column for "InfoWorld" called like the "10 Ways to Hack MFA" when I was working and writing for "InfoWorld" magazine and "CSO Online" magazine. That turned into a webinar. 

And by the time I made the first version of the webinar, I came up like "12 Ways to Hack MFA," and then that spread out to over and over, so now I have well over 50, but I've been doing this 34 years. I probably been presenting webinars and stuff for probably 30 years. And the "Many Ways to Hack MFA" has been my most popular talk by far. I have taught it to thousands of people. 

I've presented it at both RSA and Black Hat, among many other conferences. I ended up writing a free "12 Ways to Hack 2FA" book. Back in that day, we were calling it two-factor authentication, hacking two-factor authentication. And I think that even had like 18 ways to hack, and I even helped develop this tool called the Multifactor Authentication Security Assessment Tool, which is my brain. You can put in your MFA solution, and it asks you like 12 to 20 questions to try to figure out how your MFA solution works. 

And then it kind of takes my brain and tells you, well, this is how I would try to go about hacking it. So had lots of experience in both evaluating and hacking MFA. And let me say, when I say that I've evaluated 170, 180 different MFA solutions, I didn't hack them all. I mean, I've hacked probably dozens, and dozens, and dozens, but, you know, once you get a particular type of MFA, like if it's a USB key type, or it's a one-time based password token type. 

Or if it's a software versus hardware, if it's a biometric, you know, if it's a fingerprint scanner, there's a whole lot of commonality to how you would hack that fingerprint scanner, or the retina scanner, or the one-time password token. I didn't always hack all of them because they all have a lot of commonality, but I would say that all of them can be hacked, all of them. 

Even the most secure, everything can be hacked. There is nothing that cannot be hacked, but in that process, I found that there are some, a lot, that could be really hacked like 11, 12 different ways. And then other ones that only had a few, right? So hacking's not binary. Well, it is, can something be hacked? 

Yes. But then it's not binary. Go to the next slide because I'm probably talking over it anyways. But, you know, I had lots of people, lots of vendors that are always come up to me and go, "Hey, can I hack your product?" And I could. And, again, I could hack all of them one way or another. Sometimes it was even reviewing code or source code. 

You'd find bugs in it. Sometimes, a lot of times, it's not necessarily a weakness of the product, it would be something inherent in the type of MFA that it is. And it's just that, that particular type had some different ways you could hack it. Sometimes it would be because of software vulnerabilities. Other times it had nothing to do with the MFA. And I think that frustrated some MFA vendors, they'd say, well, Roger, you didn't hack my MFA token. 

You hacked, you know, Active Directory, or IP addressing, or HTTPS, or something like that. Like, I hacked something that wasn't under their control to be able to get around their product. And they'd, so, "Well, you didn't hack our product." And I'm like, "But, that's true, but it still meant that it could be bypassed by somebody." And the person relying upon that MFA solution could do it. But a whole bunch of the MFA solutions, a lot of it, the vast majority of it, I could hack over 10 different ways. 

And people were usually astounded when I shared that. Go to the next slide. So, again, the most common question I get is, can my, can this particular thing be hacked? Yes, but it doesn't mean that it's necessarily bad. There are some that are far harder to hack and only have a few ways that you can possibly even attack it, and then you've got a whole lot of others that can easily be hacked 10, 12 ways, right? 

It's not binary, it's shades of gray along a continuum from could never be hacked to completely hackable in every which way. And a lot of the MFA solutions were on the upper end that there were a lot of ways, 10, 11, 12 ways I could hack it. And then there were certainly a handful or so that went on the lower end that it was a lot more difficult to hack. 

But anyways, that's what we're here to talk about today is hacking MFA. And really what I want to encourage people is, there's lots of different MFA, and you should try to use a solution that is less hackable. And I'm going to share with you the most common hackable method used against any MFA solution, and what I'm going to caution you and try to tell you to do, I'm becoming a little bit militant about it, is that I do not think you should use MFA that is susceptible to the problem I'm getting ready to show you. 

And that problem probably impacts 80%, 90% of MFA today. It likely impacts the MFA solution that you're using today if you're not using Beyond Identity or some of the others I mentioned. But let's go to the next slide. You know, if there's any takeaway that I want to give you, it's try to avoid any MFA solution that can be easily socially engineered around or man-in-the-middle around. 

And, again, this is true of probably 80%, 90% of today's MFA solutions. It is true of the most popular solutions that most people use today, and it's a travesty. And it's not just me saying this, it's the United States government. For example, in the United States NIST, National Institute of Standards and Technology, in 2017, in their "Digital Identity Guidelines," that's NIST Special Publication 800-63, they said, "You should not use MFA that relies upon your phone or your phone number." 

They wanted it to be restricted, but that basically rules out all SMS-based MFA and all voice call-based MFA, not necessarily all phone apps because the phone app may not be tied to your telephone number, but probably the most popular MFA on the internet today is probably SMS-based. 

And the U.S. government's been saying for five years now, don't use it. And they further clarified in 2021, Biden released a presidential executive order, which is kind of, people know it as the zero trust executive order, which says you should be using zero trust, which is also yes, a very good thing to use. But in there, they actually had a clarification memo that they followed up that executive order, and they followed it up again in 2022, but read what it says here that the agency systems must discontinue support for authentication methods that fail to resist phishing, such as protocols that register phone numbers for SMS, voice calls, supply one-time codes, or receive push notification. 

That supply one-time code, or receive push notification, or use SMS, that is probably 80% to 90% of MFA. So, you know, the Google Authenticator, the Microsoft Authenticator, a lot of the most popular apps that are out there literally supply one-time codes, or push-based notification, or tie it to your phone number. 

And if they are, you should not be using them. Not only do I say that, the U.S. government says that, the president says that, and, you know, CISA, the Cybersecurity Infrastructure Security Agency. But, unfortunately, it is still the vast majority of MFA out there. And I'm going to show you a hacking video coming up in the next slide that was actually put together by a friend and a co-worker of KnowBe4, Kevin Mitnick. 

He was probably one of the most infamous hackers in the world back in the late '80s and early '90s. He eventually got arrested for hacking. He's since been a good guy hacker ever since, but he created this demo. I'm getting ready to show you, but it is... This demo, if your MFA solution can be bypassed using the method that he shows in the video, then I do not think you should be using that MFA. 

But in this particular case, the method...let me say there's lots of ways to hack MFA, but this is the one that works really, really well against most MFA, 80%, 90% of it out there. And I think that if you can look at your MFA solution and say, "Oh, I think mine would be susceptible to this too," you shouldn't be using it. 

Because the whole reason we're trying to move people from login name and password to MFA is to try to stop them from having, being phished. And if 80%, 90% of MFA can be phished relatively easily, then, you know, what have you got? But the way that this works is that the victim's got to convince the victim to go to this rogue man-in-the-middle, evil proxy website. 

So typically, what happens is that the victim will get... It can happen on a website. It can happen in an email, but in this case in the demo, the victim...and by the way, Kevin Mitnick is both the victim and the attacker in the video. But he sends a rogue email that the victim doesn't realize isn't a real email. And if you can trick an end user into clicking on the wrong link, which we know in about 30% of cases in most organizations people will click on a rogue link, it takes them to this man-in-the-middle, evil proxy website that then sends the connection to the real website. 

So what gets downloaded to the victim is actually all the content from the real website, but there is now this man-in-the-middle, evil proxy in the man-in-the-middle attack. And so everything the end user types in, their login name, their password, their MFA code can be captured by that man-in-the-middle proxy website and the attacker, everything the website sends back can also be captured. 

And part of that is they can capture the login credentials, passwords, MFA codes. And also after you log into any website successfully, you will get what's called a network access control token. It's really just a text-based cookie. But when that's sent to the end user after they log into a website, it pretty much is like a license saying you are who you say you are, and you're allowed to log into this website and do whatever we said you can do. 

But if the attacker can get that session cookie, they can take over the user's session. And let me say, this is a very popular attack. I first wrote about this attack in the 1990s, it has been done millions of times since, and it bypasses 80% to 90% of MFA. And, again, if your MFA solution can be tricked by this attack, then I think you should be trying to look at something else. 

We're going to show you the video in a minute, but if you want to watch this video later on, you can go to that YouTube link there. But with that said, I'm going to let Jasson kind of play the video, and I'll shut up for a couple of minutes so you can see the demo. 

Video playing

Kevin Mitnick, KnowBe4's chief hacking officer. So I'm logged into my Gmail account. And if you take a look in the second email here, I'll go ahead and open it. It appears to be an email from LinkedIn. And ordinarily, when somebody wants to join your network on LinkedIn, LinkedIn will actually send an email to your email address notifying you of that. 

And if you're interested, you can go ahead and click Interested, log into your LinkedIn account, and authorize that person to actually become a connection. So if we take a look here, we have an email from LinkedIn that says, Kevin, I've read about your adventures in ghosts in the wires and so on, and this person wants to join my network. 

But this is actually a phishing attack. If we take a look here at where the email is originating from, it's not at linkedin.com, it's at this domain called llnked.com, which people might overlook. So let's go ahead and pretend that we're the victim here and go ahead and click on Interested. And what that is going to do it's going to redirect us to the LinkedIn website to go ahead and log in. 

But let's move this over to the right and let that load. And if you take a look over here, we have a blank white page which is going to become very important in a moment. And this is the attacker terminal session. So let's go ahead and bring back the virtual machine that's now connected to LinkedIn to authenticate because we again clicked on Interested in the email. 

So we'll go ahead and put in a username, johnny.boy@mitnicksecurity.com. And now we're going to go ahead and put in our secret password. And then we're going to go ahead and click Sign In. And when we click Sign In, it's not going to allow us to log in. What LinkedIn is going to do is request our two-factor authentication code that LinkedIn is going to actually send to my mobile phone. 

And, in a moment, you should hear a sound that the text message was received on my mobile phone. So let's go ahead and click Sign In. And here we go. It's telling us that two-step authentication is enabled. We just heard a message come into my mobile device. We're going to uncheck this box that says recognize this device in the future. 

And I'm going to open my mobile device to take a look and see what the text message is, or what the code is rather. So the code here is 421476. We're going to go ahead and click Verify. And when we do so, it's going to log us into my LinkedIn account. So now we're logged into LinkedIn account, but let's take a look at the attacker's session over here on the left. 

So we're going to scoot this over to the right. And over here, what we have is what we're able to intercept. So we're able to intercept the email address, which is johnny.boy@mitnicksecurity.com. We were also able to intercept the password to the account, which is knowbe4rocks. And over here, this is not the actual six-digit code that was intercepted because you can't really use the six-digit code again, the second factor. 

But what we're able to do is intercept the session cookie. And if you're able to steal the session cookie or if rather the attacker is able to do so, they don't even need your username, or password, or second-factor code. They could simply load the session key into a browser, and they actually become you. So let me show you how this works. 

We're going to highlight the cookie. We're going to copy it to the clipboard. And then we're simply going to open up Chrome in incognito mode. And incognito mode just means with privacy. So now we're going to go to the real LinkedIn website. When we go here, obviously, we're not authenticated. Now it, you know, wants us to log in with our credentials, but we don't have to do so. 

We're going to go ahead and go into developer tools. We're going to go into the console, and what we're going to paste into the console is the session cookie that we stole from the victim, which was myself, by the way. I'm going to enter it. I'm going to head and close the session. 

Now, all I simply have to do to be logged into the victim's account with their session cookie is simply hit refresh now. So I hit refresh and here we are, we've logged in or rather hacked my own account. 

Roger

But if you all get interested in trying to figure out how Kevin did that particular attack, he used a freely downloadable software called Evilginx. It's been around for a decade, been getting around two-factor authentication for like six, seven years. 

There really are dozens, if not hundreds of programs that allow this to happen. If you could go to the next slide. So what I want to, you know, leave is that you should, when you're choosing MFA, and again, I've looked at a ton of them, choose a solution that's not easily phishable. You know, anything can be hacked, but again, the whole reason that we're moving from passwords, login name and password, to MFA is so that you can't be easily phished. 

And let me say, most people that are using MFA today are shocked that it can be so easy gotten around and people will say, "Oh, can it do this?" "Can it get around this?" "Can I get around that?" Almost always. I mean, the vast majority of MFA is susceptible to this particular type of attack. And I personally believe that if your MFA is susceptible to this sort of attack, you should not be using it. 

And let me say, I have a ton of vendors, probably every day, I get three to five emails asking me that they want to meet with me and evaluate their product. And I roll my eyes because they've seen my videos, they've seen my articles, and somehow, they don't think their solution is phishable. And when they show me their solution, like, I know exactly how I would phish around it and whatever. So I forget who contacted who, but I eventually ended up talking to Beyond Identity, and I'm kind of rolling my eyes going, hey, this, blah, blah, blah, and then they showed it to me, and it's not easily phishable. 

And let me say that I'm a fan of any MFA technology that is not easily phishable. And I can tell you personally, this is just me, Roger, that they've got a solution that is more secure than most and certainly is not easily phishable. And, you know, again, I am a critic, and a doubter, and a skeptic, but they did prove to me that they're one of the good guys that can't be easily phished. 

And with that...you know, when I met Jasson, we're like, okay, let's look at some demos and try to set up and let me see if I can phish past your solution. And I couldn't. And that's what I think Jasson's going to kind of show today, some of those demos and how it's harder than most. 

Jasson

Thank you, Roger. So, yeah, the first couple of things I wanted to do was really just do a show and tell, and then we can kind of talk a little bit more about how the product gets used and how we actually made it work and function in the way it does. But to start with, let's actually just flip over to a demo. So I actually recorded this a little bit earlier because the bandwidth in my hotel room is quite sketchy. 

So the setup that we actually have is we have our victim. Our victim goes by the name of Alice. And Alice is going to log into a work service. So what you see here is in the background. I have set up an account for Alice. We go ahead and spill the beans upfront. 

Alice's password is Feb2022!. But what we do is we have two different scenarios that we have set up in the back that we're going to try and...that we're going to phish. So one is a scenario with just kind of a traditional enterprise SSO and MFA solution. And the other is with that same SSO solution, but with the Beyond Identity authentication and kind of zero-trust access experience. 

And I'll get in and talk a little bit more about what all of that means in a minute, but just a little bit of background about what's going on. So I didn't spend too much time trying to come up with clever lures and emails to get the victim to actually click on a link. I think we kind of all understand that, that is an art and there are people that are very good at that. So I just jumped straight to we can get someone to click on this link. 

So what happens? What does it look like in this setup where I have a common enterprise SSO with MFA integration? So I'm going to go log in. Looks normal. What's my username and password? I keep it in my handy-dandy password manager. Let me copy it over. 

I love Alice and Bob as names. They, for those of you that are slightly old. 

Roger

The crypto world. 

Jasson

We're getting an MFA pop, let's make sure we take care of that. What do you know? I'm secure, yep, that's me. Because it is me. I'm trying to do a thing. At least I think I'm trying to do a thing and now I'm into my service. And just to show you, yep, this is me. It thinks it's me. 

Now, there are a couple problems with this, right? We were just man-in-the-middled, we're being relayed by a proxy just as was demonstrated a minute ago. But let's go on and see what happens. So now we're going to show the other scenario. And after we show the other scenario, we'll flip back and get a little bit more detailed under the hood. 

But the scenario we're about to do is we're going to log out, and we're going to log into the SSO that's, where we've actually integrated with Beyond Identity. And you'll see what that experience looks like. So let's say I've been phished with this link to the other setup. And I managed to land at the man-in-the-middle proxy. Now, one thing off the bat that you might notice is there's no password. 

File that in the back of your minds. We'll come back to that. Oh, crap, I forgot my name. What is it? Oh, yeah, it's Alice. Now moving forward, and you'll notice a different sequence of events start to happen. And ultimately, that sequence is going to result in a failure. 

Like, I'm unable to really move forward. And I'm going to tell you why here in a second. Okay. So here we're getting in under the hood. So this is essentially, you can think of it as the output log from the man-in-the-middle proxy. So I have two of them running up. One of them was responsible for man-in-middling the traditional MFA solution. 

And the other was trying to man-in-the-middle the Beyond Identity solution. So in this first scenario, you can see clearly that not only did I capture the username and the password, but I was also able to capture the JWT, the access token, which is just as useful, right? I can do as you saw a minute ago, log into that active session and start changing things if I want. 

Just in case you didn't know where it was, I highlighted it there, and just to show you a little bit more information about what was actually collected. Okay. Now, this is the solution where I tried to man-in-the-middle the SSO with Beyond Identity, and you'll notice I never captured a password. 

And if you remember correctly, a password was never actually entered, but also the authentication session never actually completed, it failed. So not only did I not capture a password but there was no access token, or there was no JWT produced at completion. And there you go. 

I'm showing you where you should look. All right. So before we end the demo, I would be remiss if I didn't actually show you what the happy path looks like. So I'm going to log into a service. Now, this is actually a live service. So you're going to see a slightly different sequence. 

Because I have access to certain applications, the machine is going to escalate its challenge to me. And I'll explain a little bit more detail what that is. But part of the challenges is it's actually asking me to prove I can use something that's protected by an enclave and guarded by a biometric and/or a local PIN. And once I do that, I'm actually allowed through. 

Roger

And this is the way it's supposed to work. If you're sent to a fake website, it should not work. 

Jasson

So what did we just see? Let's kind of talk about that in a little bit more layer of detail. So I'm an engineer at heart, and I apologize if any of you are rolling your eyes right now, but I love these sorts of things. I love sequence diagrams. It was kind of how I learned network protocols and network systems a long time ago. And it's, for good or for bad, it's just how I imagine the world, right? 

So I'm sure some of you have seen these before. They're just sequenced diagram. They help us visualize what's actually going on. So we have the victim or Alice off to the left, we have the adversary in the middle, and we have the SSO off to the right. So I have two versions of this slide. The first one is just maybe, there's the victim that's going to get phished and there is no MFA present. So when the victim clicks on a link, they don't go to the SSO site, they actually go to the adversary and the adversary proxies that request. 

And that ensures the adversary gets included in the response. So when the response comes back and the victim is supplying their credentials, the credentials are actually going to the adversary. And then the adversary, of course, can just proxy those credentials. And now they've captured the credentials, and then, of course, because those credentials are correct, they'll also receive the access token on the end. 

This isn't terribly exciting because it's a step simpler than what we just described, but think of it as like the building blocks, if you will. So now let's add a second factor. And in this case, let's add a push factor as a notification. In the demo, you saw that this really didn't do anything to defeat the scenario. And in this sequence diagram, we kind of show you why. 

As far as the service that you're logging into is concerned, it really can't tell the difference between the adversary and the victim. The 2FA has a direct channel to the victim. You've coached the victim into trying to actually do something that they think is legitimate. So you kind of have a willing participant or signing fool, if you will. And that's how this is actually able to be pulled off. 

So, again, up until that first theft of credentials, everything kind of looks the same, but then the SSO engaged the two-factor, whether it's an SMS push, or a TOTP insert, or, as we saw, a push notification. Because this happens out of bound and because there's no real kind of channel or transaction binding that brings all these things together, it's very difficult for any of these systems to really know what's going on. 

And, of course, we get the same result, a theft of credentials as well as a theft of access token. Now, again, this is one way of harvesting credentials. It's a lot easier to just go to password sites and get dumps if you really are interested in credentials. This is more interesting because you're getting the access token, right? The access token gives you immediate power. So let me talk a little bit about Beyond Identity, and then I'll go to, well, how did ours work to make that a little bit more clear. 

So here at Beyond Identity, we have built basically an identity platform from the ground up with the idea that we're trying to service a security audience. We want to be the first identity stack built to present security controls to a set of security admins and help them actually improve the end-user experience while actually being able to answer the questions of, what is the likelihood of the person who's claiming an identity at the time of access against the criticality of what they're trying to do? 

And what's the security posture of the device they're trying to do that from? If there's some way for us to take all of those three things and anchor them together to where we know that the parties that we start the transaction are the same parties that we end the transaction with. And we have some sort of hardware level of trust, then we could really start to change the game. And I have this bad habit of talking about slides that come later, but in literature, they call that something. 

What is it? Shadowing, foreshadowing. Anyway. So now let's go back and see what we saw. Okay. So this is the phishing-resistant flow. So, again, remember the two setups. 

Scenario number one is I took an SSO. And in our scenario, we used Okta because we love Okta. They're a great partner. We work with them in a ton of our production accounts. And we showed how to actually have a phishing-resistant SSO with Beyond Identity versus a more legacy provider. And the way it actually worked here is, of course, everything always starts off the same, right? If you can get a victim to click on a link, you're always going to start off with a proxy being in the middle of a particular sequence. 

But when Beyond Identity gets engaged to actually delegate the authentication, we actually start to run this challenge-challenge response process. So you all are probably familiar with classic password authentication, right? You want to log into a service, that service sends you, they call it a challenge, but think of it as a random string. 

And if you're able to permute that random string in a way that you know how to permute and the back-end service knows how to permute, then bing, bang, boom, must be the right password. Well, with asymmetric cryptography, it turns out you no longer have a shared secret, right? You can actually just publish may be a public key and just keep a private key. But in addition, we're not just trying to prove the victim is, or the original subject is who they claim they are, but the service they're authenticating to also needs to be able to prove to the victim who they are. 

And there needs to be some way of adjudicating that those two things are, in fact, the same thing and nothing has come between. And we're able to do that through a sequence of challenge and challenge-response sequences where we actually kind of sign the payload so you get this nice tamperproof resistance. The cryptography is anchored in hardware and I'll tell you what that means here in a minute. But ultimately, we're able to kind of catch that sort of solution because it's very obvious upfront when we go to receive that challenge, it's obvious it did not actually come from the adversary and it just shuts down. 

Okay. So what does it look like at a high level, and then we'll drill down a little bit? So most security incidents start with a valid credentials use, which is a really technical way of saying most companies aren't getting security results from their identity stacks. So how do we change that? 

That's really kind of the mindset that we've had from the very, very beginning. So we built an identity stack that could plug into really all of the incumbent SSOs that you may have already deployed. And off of that identity stack, we paired it with this thing called...what we call a platform authenticator. I shouldn't say we call it, we actually borrowed the language from the W3C, if you dig into their webauthN specification, I think they actually introduce that terminology, platform authenticator. 

But what it basically means is we have an authenticator on the endpoint, on the machine that someone's trying to do something from. And this starts to give us a precipice from being able to actually make claims about the person and the device, as well as check validity of challenges coming back to the device. We've introduced a policy engine in both our cloud and that platform authenticator so that when someone wants to access a service, you know, risk and risk acceptance aren't black and white. 

Every company has a different risk acceptance familiarity, capability, willingness. And even workers within a company or customers within a company might have different willingness or different needs. 

Or put simply, if I'm doing a low-risk activity, maybe you don't really need a lot of security controls in place. If I'm doing a high-risk activity, maybe you do need a lot of security controls in place. So our policy engine kind of lets you dial it in. Obviously, you can do it at the company level, but you can drill in and you can do things based on groups. 

You can do things based on applications that the person's trying to access or do certain things in. And the way that we roll that up is whenever there's an access request in our platform, our policy engine will send down a challenge. And a challenge isn't just to prove you can permute this random sequence of data, it also proves that you can use a private key guarded by a biometric or a local pin, and that your firewall is enabled, and that your disks are encrypted, and that this value does not exist in your registry or your Plist file. 

And that your operating system version is greater than X, Y, and Z. Like, it's almost anything that you could imagine from writing a hunt query over. You could actually build policy around to really, kind of, in a fine-grain way, carve out different levels of risk and just respond differently. And, of course, the anchor for all of that for us is a trusted execution environment. 

So this last slide is more about like how do we bring it all together? So as of 2016, it's very difficult for you to buy hardware that doesn't come with something called a trusted execution environment. Now, a TEE or a trusted execution environment, it's a categorical term. It's not a product term. 

Different companies have different products that fulfill that nature. The one you probably heard the most is a TPM, a trusted platform module. But there are other versions of this technology, right? Apple's T2, Arm's TrustZone, Intel's SGX, Amazon AWS's Nitro instances, and they all provide similar things. They allow you to create or they provide physically a tiny processor that's isolated from the main processor that you can construct asymmetric credentials in that can give you guarantees about how those credentials are managed across their life cycle, right? 

It's possible to create a credential that can't come out of that piece of hardware, that can't move. And that forms a trust anchor for you to start really doing some interesting things like basically knowing that I'm always talking to the same device. Now, as Roger said earlier, you know, security is a game of raising the cost, it's not a game of absolutes. 

And, you know, there have been some sensational articles over the last couple years about TEE technology, in general, but the really interesting and the simple use case of TPMs at the core, right, which are signing keys, have never really been part of that. 

What I really mean is they provide a really, really strong guarantee that I'm talking to the device I actually expect I'm talking to. They provide an ability to actually do things called taking measurements of the software. So you can say not only prove that the user can access a key guarded by a biometric but prove the user can access that key, and they're running a version of Windows that has been unmolested, that hasn't been modified in any specific way. 

So there's all these sorts of really interesting properties of the TPM. Anyway, we exploit that inside of our platform authenticator, we also exploit the device posture capability, and we wrap all of that up inside of our policy engine in the cloud. This runs today on all the major operating systems. It integrates into the back of your SSO pretty seamlessly. 

If you're running in Okta, it takes about 30 minutes. If you're running a Microsoft solution, it takes maybe an hour or two because Microsoft's a little higher on the complexity curve in terms of configuration management and whatnot. And we support a ton of systems in between those two as well. We've mostly been talking about the workforce solution, but we also can take charge and manage cryptographic material for like technical use cases. 

So, for instance, everyone in software development talks about code signing, and they're really talking about like, is the build artifact signed so I know I'm running something that's genuine versus not genuine? But one of the dirty secrets of development is no one's code that they're actually committing to a repository has any sort of integrity protection back to them as an identity, and certainly not to the device they did it on. 

And so we have ways of actually kind of plugging that hole without requiring the developer to even change their workflow. They just keep typing git commit, and all of a sudden, all of their commits have like a cryptographic relationship back to their identity. Anyway, that's kind of the very quick use cases and kind of how we bring these things together. I'd be remiss if I didn't tell you a little bit about the company at large. 

We are about two and a half years old. The story of the company founding from a story arc perspective is really, really interesting. So Jim Clark started a company called Silicon Graphics, which was actually one of my first work computers way back when, but he also founded a company called Netscape that's definitely important in terms of something that you all most certainly interacted with. 

And at Netscape, Jim and the team built out a solution called SSL that helped commerce come to the masses on the internet. And they really kind of punted on client authentication at the time because it was hard, the model wasn't clear, and there were so many other problems they were trying to work through. And when Jim and TJ were kicking this around three years ago, one of the thoughts they kept coming back to is why did we ever not really look at the client-side of an SSL connection and figure out a better solution than usernames and passwords? 

And the genesis of the company has kind of come out of there. So we're now just under 200 employees, we've got engineers on 2 continents, we've got customers on 2 continents, and we're building a zero-trust access solution that's easy on the security admin staff, it's easy on the end users. It's 30 minutes to try it out. And, you know, maybe it's a like a Billy Mays commercial, you know, give us 30 minutes, and we guarantee you won't turn it off. 

So that's the end of the slides. And, I guess, now we'll kind of turn it over to Q&A. 

Tom

Beautiful. Hey, Jasson, Roger, thank you so much. We do have the opportunity for questions now. And a reminder, attendees, if you've not submitted your questions yet, do so now. Might not get to everyone, but for those we don't get to in the course of this session, we'll get responses back to you via email. First question I have, gentlemen, "What exactly do U.S. regulations now say about who and how companies should implement MFA?" 

Roger

So, I guess, you know, I can take that one again. I kind of covered that in my talk, you know, so it's been missed, the U.S. government presidential order, CISA, Cybersecurity Infrastructure Security Agency, they're all saying don't use these weaker forms. Matter of fact, I got to say, it seems like a big disconnect. 

Like, if you have the United States government, since 2017, saying don't use SMS-based MFA, how can it be five years later that it's still probably the largest majority type of MFA used on the internet. It's some type of weird disconnect, but they've since even matured, and said, hey, like, you know, any type of MFA that says one-time code can be phished or even push-based. 

Like, I was a big fan of push-based MFA for a couple years. Matter fact, I've seen some of my older videos, I'm like push-based MFA is good, but it turns out it's very easily phished and real-world attackers will go up to single factor push-based MFA and ask people, hey, you know, push-based MFA is where you get that approval, you know, are you logging in? 

Yes or no? And it turns out about 30% of the people that are phished to push to allow someone to log in will say yes even when it's not them logging in. And the U.S. government realized this is not a really strong viable form of protection. And so the U.S. government is telling us exactly in writing over and over again what not to use, but it's still the vast majority of the stuff out there. 

And I think that's a problem. 

Jasson

When I learned about push fatigue, it reminded me of alert fatigue, and it's almost like a psychological trigger point, right? Like, you can only have heightened alertness for so long. And if the adversary can exhaust that mental reservoir, finally, you're going to just say, "Yeah, I guess it's me. Go away." 

Tom

The question about the demo, "Was this just a theoretical example for the demo you showed, or does this actually happen?" I think people might be surprised. 

Jasson

No, this actually does happen. An incredible amount of resources are put into not just trying to prevent it from happening, but also trying to detect it from happening. I'd say most companies today typically respond to these as incidents as opposed to have any sort of real capability towards prevention. 

Obviously, that's something that we would like to help with. And that kind of goes into our general message along the lines of, you know, if most of your security incidents are starting with valid credentials use, like ask more or your identity stack and make it become a real security product, and, you know, wouldn't you like to prevent fires rather than putting them out? 

Roger

Yeah. And let me say, not only is it been occurring for decades, these particular types of attacks we showed, but they have occurred millions of times, and there are thousands of bots that automate it. Like, you don't have to be an uber-hacker like Jasson or someone, and, you know, know the ins and outs and how you're going to capture their token, and they don't use Evilginx, they're using some automated bot, one of the thousands that they bought from somebody else. 

Almost all mobile Trojans that get on people's phones have this functionality built into them today. It's a very common thing. 

Tom

"Now the recommendations you made, are these recommendations for internal security? If so, what about for customers such as a customer of a bank or an e-commerce site?" 

Jasson

So this is recommendations for any access, any authentication should actually be using strong factors, should be using multi-factors that aren't phishable, should be taking context into account. Like, it doesn't matter if it's a customer or a worker, right? 

Like, at the end of the day, a worker can hurt your business just as much as customers losing faith in your business. 

Roger

Yeah. And what I would tell people is, you know, if you're considering MFA, show them that Kevin video, go to your MFA vendor salesperson and show them the Kevin Mitnick video or the Jasson video if you have it, and just say, can that happen with your product, right? And hopefully, they're saying no, honestly. But let me tell you, the vast majority of it out there, the stuff that most people are using, it's that easy to phish. 

If I can get you to click on the wrong link, it's game over. And that seems to me to be the antithesis of what we're trying to get by moving people to MFA. So I really do want to encourage people, if you're going to look at an MFA solution, whether it's Beyond Identity or whoever, you want to make sure that it's not easily phishable, and it's not just me and Jasson saying it, and Beyond Identity, it's the United States government presidential order, you know? 

Jasson

Multiple apparatus of it. 

Tom

- Well, gentlemen. Roger, Jasson, thanks so much for your time, your insights. I really appreciate your presentation and taking time to answer these questions. Thank you.