Cybercrime – Credential Theft – Part 2/4

Cole French:

Keys to the kingdom in the hands of attackers, every organization’s worst nightmare. The immediate question is, how could something like this happen?

This question begs another question, that all of us in the fight to secure our organizations need to answer. How can we prevent attackers from gaining elevated access to our organizations? Tune in for this, part two of our cyber crime series, where we discuss credential theft, what it means, how it happens, how to respond, and how to prevent it.

Access control is a problem that confounds nearly every organization, no matter its size or complexity. The stickiest aspect of access control is the management of privileges. Privileges introduce, in some cases, exponential complexity to an already complex problem. The usual organizational churn, role changes, hirings, terminations, migrations, and the like, adds another set of complexity layers. It’s no wonder then that credential theft is the most successful attack vector out there. Credential theft is just the beginning of access control compromises though.

As we’ll discuss in today’s episode, poor privilege management is the driver of credential theft success, which for attackers is gaining elevated access. Joining us again for Part 2 of our cyber crime series is Terry McGraw. Terry is a retired lieutenant colonel from the United States Army and now serves as the CEO of Cape Endeavors Incorporated. Terry brings over 20 years of experience in cybersecurity threat analysis, security architectural design, network operations and incident response across both commercial and government sectors. We hope you enjoy this episode.

Terry, thanks for joining us again here on part two of our cybercrime series where today we’re going to talk about credential theft. So let’s just go ahead and set the stage. If you could just give us an overview, what is credential theft? Can you give us a couple of examples of how it occurs?

Terry McGraw:

Sure. And oh, by the way, thank you for inviting me. I really do enjoy doing these, so I appreciate the invite. Well, I think before we jump into what is credential theft, maybe it’s important to sort of just say what is a credential? I don’t want to be overly basic, but I do think it’s kind of helps to set the stage for those in the audience that may be less than technical. So credential essentially is how do I prove that I am who I say I am when I’m logging into a device system or service to which I want access. And credentials, we tend to talk about it in terms of what I know, who I am and what I have. So what I know is my username and password. What I am might be a biometric, my fingerprint or a facial scan. And then what I have may be the device itself or maybe a cyber token. And some combination thereof is what we consider credentials or credentialing.

And this is how we basically authenticate ourselves to those systems and devices that we want access to. So that’s credential. So the question is why is that a problem? Well, particularly around username and passwords. Passwords in particular, the cyber threat landscape has evolved to the degree where I’ve made maybe the controversial statement that passwords are nearly useless for a security efficacy. They provide us a sense of security, but that that’s security doesn’t really actually prove out in the real world anymore. And why? Well, because the cyber crime marketplace and cyber crime in general has figured out how to harvest those credentials. And credential harvesting, meaning I’m stealing those credentials essentially. And generally speaking, it happens in a few ways, largely by fooling another human, like fooling you into giving up your username and password. So one of those ways is through a phishing attempt, an email. Sends an email that looks legitimate.

And with the advent of ai, if phishing emails get way, way more sophisticated, they look more and more authentic. And as such, people can be fooled even more easily than they were before. And then they go to the hyperlink website and they fill in what they believe is a legitimate request for their username, password and lo and behold, now the cyber criminals have it. They can also harvest your credentials through what we call info stealing software. So that can be a website that you would normally go to. If you order your supplies from a certain location or you tend to frequent a certain information repository. Either they can put in a cloned website or they can compromise that actual website and they embed info stealing software. So when you log into that server, they’re harvesting your credentials at the same time. And the other problem with this is we’re all creatures of habit. We all have only so much memory available. We’re just like the computer in some ways. So we tend to reuse our passwords.

Look, we all kind of do it, and if I can harvest your username and password from one website that I’ve compromised or one mechanism of compromise, I probably have a likely probability that some derivation of that password is probably in use in other locations. So you could harvest it through a compromised website and info stealing. And then of course through illegitimate websites on legitimate Google searches. So for example, when you think you’re downloading let’s just say it’s WinZip or some... You Google your favorite software that you want to download, and through search engine optimization poisoning, the first three links are really just either fake locations with something similar or it’s actual malware being delivered. And inside that malware is the ability to capture username and passwords off your system.

Same can be delivered through phishing. Like the Qakbot software for example, which is now defunct, but was popular from 2007 until last year. Incredibly powerful software delivered through email mostly. And so those capabilities exist, a plethora of them, and literally tens of millions of passwords are harvested every year and are freely available in the underground marketplace. So I can steal them through you just giving them. And as I mentioned, there’s software that can be delivered to your system that can harvest them off your system and there’s keystroke loggers, et cetera, where I fool you into entering them.

The other reality is any user that logs into a particular system, and if there’s multiple users logging into that system and they have multiple profiles or even your network administrator logging into that system, there’s going to be a username and a hashed version of the password stored within the memory of that computer and that too can be harvested. So the credentials that I use to log into your system to remotely help desk, for example, if I’m using overly broad permissions, that username and password can also be harvested. It can be captured through things like Mimikatz, then the password can be cracked and then re-entered. So that’s part of this credentialing process. So username and passwords at this point, like I said, they only provide the semblance of security, the near of security, but very little actual security efficacy are provided by username and passwords.

Cole French:

Yeah. I’m going to pull the thread a little bit on the phishing thing because I think we see phishing a lot. And actually I guess we just ran a phishing simulation, and I got a message yesterday to what you were saying about AI being a player now in developing phishing emails or campaigns and the ability... Historically, the problem with phishing has been you could spot them pretty easily because there was spelling errors or there was kind of goofy things going on. But yeah, I think you’re right. With AI, we’re going to see that become less of an issue with phishing. This is just a reminder for folks out there, it really comes back to look at those messages and don’t even look at do they look legitimate? Just look at who are they from, right? The message was that I needed to transfer files. That someone was inviting me to share a OneDrive with them, and the message was completely legit.

Just looking at it, there was no spelling errors, the OneDrive logo looked legit, all that. Looked just like you would expect it. But I stepped back for a minute and I’m like, “I don’t know who this person is that’s sending me this, and I haven’t asked for this. I haven’t done anything to initiate this.” And you just stop right there. I think that’s the reminder with these messages that we get. Getting unsolicited messages like that is not normal. So just something to keep in mind when talking about phishing stuff, since like you mentioned, that is one of the primary vectors of credential theft. And so given that that’s a vector of credential theft, obviously phishing would also... And some of the stuff you just talked about is also a cause of credential theft. But can you take it sort of a step or a layer deeper into what are some of maybe the hidden causes of credential theft, the stuff we don’t necessarily think about on the surface?

Terry McGraw:

Yeah, so I’ll give you an example and maybe this will help drive the point home. This is a vignette. This is a real world incident response engagement I was involved in. I’ll anonymize it to protect all sources and any potential liability of course. But a financial services company had an employee that received an email around tax time of last year and it says, please update your W-4 form. And it gave a link to what seemed was a OneDrive drop. They didn’t really look all that clearly to whom it came from. By the way, a lot of these cyber criminals will use very similar domain names. They’ll just be either slightly misspelled or instead of a .com, it might be a . something else. And so it could be just one letter off, but it’ll be a spoofed email or they might already have a spoofed email, in which case it does look like it came from an internal source, but in the process of clicking on that link, so number one, the subject line is something that generates your interest and it looks legitimate.

The content of the email looks legitimate, but you click on it. So let’s talk about the mechanisms. What’s happened next? So for example, before I get into my little vignette, I will clue you in that we’ve spent a lot of time, a lot of money implementing multifactor authentication. We’ve been advocating for it because of the inherent weaknesses of username and passwords. But even the token itself is not immune to harvesting if it’s not set up correctly, right? Which is why we’re going to talk about a passwordless or a passkey environment here shortly. But even multifactor authentication can have the token harvested, and I’ll explain that as we go through this vignette. So financial services company, the user gets an email asking them to update their W-4 form. The user goes to thinking it’s legit. So when they click on the drop to get to the form to update, they’re asked, they’re prompt for the password.

Okay, step one, they’ve just harvested your username and password. And then a multifactor authentication request is generated, right? So that malware then pushes a request to log in with your MFA. It’s actually a man in the middle attack person in the middle, however we want to say it these days and what it does is acts as a proxy. So it will request the information from the user, at the same time it’s sending a SUDO request to the actual authentication server of the enterprise. And so the username and password is captured on entry by the user, that is sent on to the authentication mechanism. The multifactor authentication kicks off, sends it back. The proxy of the man in the middle attack captures the request. And then of course, when you respond with your MFA token, that token is then captured and the two are then linked and they immediately log into the system.

And so that’s sort of a proxy attack for man in the middle where they’ve captured the username, password and your multifactor authentication token to complete the connection. And by the way, that illustrates the weaknesses in both of those approaches. But then let’s follow the click down. So now the adversary has a user’s username and password and multifactor authentication. Now, granted, the token is only good for a very short period of time, but the malware or the system that’s being used automatically logs in with that. So the system then accepts the user login because it’s happening in sort of that same communication stream of the request to the phish. So the systems that are responding to it then allow the adversary to log in as a legitimate user. Now, the access could stop there, meaning if it’s just an average user, there’s no other credentials on that box. They’re just using that user. They can access whatever that user can access, your SharePoint, your email, and those kind of things.

But the ability to maneuver and laterally move through that environment is restricted to only what that average user could actually natively access. Where it becomes more problematic for an enterprise is when that access that’s granted gives the adversary the ability to now start querying things on that box and bringing in other malware. So I’ve logged in the adversary now looks like a legitimate user, and then they will launch other software capabilities to then bring in more tools for them to use. One of the first steps they do is they harvest credentials. So they will dump from memory all the users and the hashed passwords that are stored in the LSAS of the operating system, and they’ll take it offline and then they’ll use multiple cracking tools to then crack the passwords and then log back in. Just for everyone’s awareness, there’s cracking software available right now that can crack up to 14 characters.

When you hit the 15th character, you get back to a level of entropy that would take several hundred years, but believe it or not, 14 characters can be cracked in an hour or less by tools like the Secureworks Crack. And there’s lots of Cracking software out there that now when you marry the software capability with hardware capability, you can crack up to 14 characters. And so as a consequence, most folks in their day-to-day operation probably don’t have a password complexity above 15. And so as a consequence, they can harvest those usernames and passwords. Again, not really a big problem for the enterprise except, and I’ll use my vignette again of going back to this example for the instant response engagement. The threat actor convinced this person, the user to log in. Once that person actually logged into the drop and went to access the document, the document itself contained Qakbot, again, as I said, the FBI took that system down and the threat group’s infrastructure down in 2024.

But as I said, it’d been up since 2007 and been curated and improved over time in all those years. And so it was incredibly powerful software. That software had the ability to self-propagate. It could do enumeration. It could laterally move based on connections. It could do browser hijacking. It could harvest email. It could do a keystroke logging, harvest credentials, et cetera. And it had a VNC capability, it had a reverse shell capability. So the user or the adversary that has the Qakbot once on that box had a lot of capability to maneuver to start maneuvering in the environment. But it’s still predicated on finding a user account that has elevated privileges, administrative privileges to do something in the environment a normal local user couldn’t do. In this particular case, a network engineer made the mistake, which has happened a lot where because of ease of use, they were doing some administration at the top level domain, they logged in as their global admin, which has domain level credentials, and they started working help desk tickets.

Now here’s the problem with that. That privileged account they were using is the highest level you can get usually in an enterprise environment, and it should be restricted and best practice to only being used for your top level domain controllers and only at your Tier Zero. It’s very, very limited use because the general admin account overrides all others and has the ability to do all kinds of things. Unfortunately, for this particular company, the network engineer just used their global admin account to go ahead and just start knocking out the help desk tickets. And guess what they did? At some point in the recent past, they’d logged into the user that fell victim to the phish, and the threat actor was able to harvest not only the user from that box, but they harvested the global admin account and password that some network engineer had foolheartedly used to do just administer local endpoint help desk kind of ticket remediation.

That allowed the threat actor, once they’d harvested it, they took less than a couple hours to realize that contained in the credentials that they’d stolen was the keys to the kingdom, and they logged right back in as the top level domain admin. They proceeded to create another couple admin accounts, kick out every other admin in the company and then take over the entire environment. So then they went and they disabled the EDR, their endpoint detection and response capabilities. Because this company also had other shares, etc, that were tied into that, they literally enabled the threat actor to not only own the entire environment, but to rapidly deploy the malicious encryption binary and lock up the entire system. So fast-forward. So that’s I guess an extreme case of credential harvesting that starts with the seemingly cliched phish, but then ends up owning an enterprise.

Now, there was a slightly good news story in this story. They were smart enough to have a break glass account on their active directory, and that break glass account allowed them to then wrench control back of their active directory. And then of course, they had to reconstruct their active directory over the weekend. But this company lost literally tens of millions of dollars an hour while they were fighting to get their network back from the adversary. So it can have devastating consequences. So that’s credential theft at its seemingly worst is when it can be used in that manner.

Cole French:

So, going back to the character length of passwords. I remember, 2008 to 2010 timeframe, I remember it being eight characters was the level of entropy you needed and now it’s 15. Let’s say, 2010, I don’t know what the progression has been, but it just shows that in a very short period of time that the ability of systems to hardware and software to catch up and be able to break these passwords is changing and frankly shortening pretty rapidly. I guess that vignette that you just shared also tells me that it’s not just the credentials that are stolen from, let’s say me as a standard local user, but it’s also my credentials being stolen potentially could lead to others credentials being stolen.

So that gets to, I guess my next question, which is when we talk about causes of credential theft, phishing and the vignette that you just described, which obviously included phishing at the beginning. To me, and maybe you can talk a little bit more in detail about these, but it goes back to awareness and training of our users, number one. And number two, conditional access policies and configurations and ensuring that access and is configured appropriately, given to the appropriate users and then those users know the appropriate circumstances within which they can use those privileges. Is that right?

Terry McGraw:

Yeah. So Microsoft has had their tiered security model framework out for a very, very long time. I reference Microsoft because active directory is nearly ubiquitous. It’s not the only authentication mechanism out there, but it is certainly the 900 pound gorilla in the marketplace of how user object, permission, schemas, identity access and privilege access management is implemented. Now, there’s augmentation around active directory. But generally speaking, active directory is sort of the most prevalent tool out there for providing identity and privilege access management controls. And so Microsoft has published their tiered security model. And I’ll give you sort of where it was before Entra ID and the Azure architecture sort of took front and center, but sort of the on-prem version of active directory. And it’s basically said that Tier Zero is your domain controllers and Tier Zero should only be accessed through very, very, very restrictive policies.

Number one, it should be how many accounts you have. That can be domain controller. Admins should be limited to two or three. You should have one break glass account in case all hell breaks loose. And you have a threat actor that’s managed to get in, and you have the ability to wrench control back from your environment. And oh, by the way, that only accessed by your admins through a privilege access workstation or equivalent. Meaning if you’re accessing even remotely, you’re putting in controls where everything that touches that domain controller is now considered Tier Zero, and the security levels around that need to be the most stringent you have. Meaning you’ve employed exceptionally long passwords, you have a token to access them, a cyber token preferably, a five to two compliant device. You’re doing all of the things you can, implementing behavioral based awareness of your account, etc, etc.

So Tier Zero is the most hardened of your environment. Tier one of that security model then is your enterprise management, meaning all the servers that make your business run, that’s a separate set of credentials your admin can’t log in or should not log in with their Tier Zero credentials. They should have another set of credentials that they only do enterprise management with. And then a third set of credentials or your tier two is your endpoint management, your help desk kind of configuration, your local admin support. So that is their tiered model. Now, I fast-forward to Entra ID. Entra ID Maintains that in principle, but they just make it a lot easier to implement role and based groupings that provide more granularity and to who can do what. It makes the administration of it easier. Not bulletproof of course, you have to do it correctly.

They make it easier to manage. They also make it easier to shoot yourself in the foot. But I say all that to say that’s the tiered model that we should employ. Oh, by the way, it’s not just a user like a human user, it’s also service accounts. So service accounts are system accounts that have privilege that allow us to run systems across our infrastructure. And ensuring that those service accounts are also following best practice and are also following a tiered security model and also have password rotation and password complexity and have user behavior analytics for service accounts. Do we know when they’re added? Do we know when they’re subtracted? Do we know when they change? Do we know when they’re used? Do we know where the boundaries of the service accounts? Are there overly broad permissions for what that account needs to do, etc. Etc.

And so all of that account management are things that the tiered security model is really meant to address. And it’s been out there for years. But a lot of companies have a fairly flat network. They certainly don’t tier it Administratively, much less have the adequate controls around it. So that’s why the credential harvesting and password can be so devastating. It’s not just the individual user, but it’s the compendium of controls and privilege escalation paths that can be accessed by any given user. Even if I’m a normal user, let’s say I have a service account that’s on that box and I harvest the credentials, that service account is just as useful to an adversary if that service account like traverses the security tiers, right? I can find attack paths all the way up to the domain controller by a misconstructed active directory tree.

Cole French:

I think another thing to add on service accounts, and this is historically working on the operations side and working with privilege configuration, privilege management, a big issue with service accounts also is the usage of those service accounts. And by that I mean, say I’m standing up this product that has a service that requires a service account in my environment. That’s great. So I set up a service account for that and I locked down the permissions, but then I need to set up another tool in my environment that also needs a service account. Well, I don’t really feel like setting up a service account. I already have this existing service account, so I’ll just use that. And over time what happens or what I’ve seen happen in organizations is the same service account gets used across a ton of different services.

And like you said, crossing the security tiers or different boundaries, but also crossing into different types of systems and being reused over and over again. Not only does that create a security risk, but it also creates an operational risk because now if something happens to that one service account, it’s tied into everything. Maybe not everything, but it’s tied into a whole bunch of things that run inside your organization. So I think service accounts are kind of a hidden sort of killer, if you will, inside organizations that they kind of just grow over time.

Terry McGraw:

Yeah. And they’re not monitored often. And certainly they’re not managed and monitored to the degree that we consider normal admin accounts. At least they’re supposed to be, but they often are not. When was the last time you did deliberate [inaudible] resetting in your environment, which is also best practice? Are you sure or not sure you’re going to break stuff based on your lack of doing exactly what you said, which is proper service account management in the environment. Even if you had to then go update it, are you going to break a whole bunch of stuff because you misused it to begin with?

Cole French:

So the way in which we configure credentials and maybe more so access associated with those credentials, and then how we use that access, right? I really like the tiered security model that you went over from Microsoft. Besides just making sure everything’s configured correctly, what are some other things organizations can use to protect themselves from credential theft?

Terry McGraw:

Yeah, so a few things, I think, so maybe I’ll take it reverse order. At the enterprise level, there’s things that you can do to help lock down your domain level credentials and your most critical credentials, things like CyberArk and BeyondTrust, etc have the ability to manage those accounts and keep them more secure. Again, if your entire architecture is not set up correctly, that helps, but it’s not like that’s going to be a panacea. Once you’ve implemented those tools, you have to make sure that you’re doing all the other things correctly as well. But they can help at the enterprise level to help make sure you’re locking down the keys to the kingdom and making it far more difficult for an adversary to access those things that can do the most operational damage to you. As you work your way down to the individual user, but supported by the enterprise is moving away from username and password to begin with. This is what the FIDO Alliance was designed to address, and FIDO stands for fast identity online.

And so a lot of the big techs, Microsoft, Google, Amazon, you name all the big ones, got together and said, “How can we make a more secure authentication framework that users will adopt?” And maybe not even adopt, but actually enjoy? And so a few things have come out of the FIDO Alliance, but essentially what the FIDO Alliance does is try to invert the equation of authentication from the enterprise and a server within the enterprise providing sort of the pairing of a user’s credentials and then access into the system, but inverting it so that the authentication actually happens at the user’s device, whether that be through a token or whether that be through an authenticator app or on the device itself, like within a trusted platform module where instead of a username and password being sent and then compared to a credential that’s stored on the server and then a token being generated and then matched to the user. The FIDO Alliance sought to do the, instead of that username password exchange, create a public-private key scenario.

And I don’t know how this will resonate with the listeners, but a public-private key. It is a very long and well-defined encryption methodology of exchanging keys for access. It’s based on the Diffie-Hellman algorithm, but essentially a private key, which you as a user own, is married to a public key that is freely available, and it is only through the matching of that public and private key. And the matching of that creates an incredibly, incredibly powerful encryption algorithm that’s, let’s just say virtually mathematically impossible to reverse engineer once that public-private key are matched and creates the certificate that is then granted. But that public-private key exchange is a very, very, very powerful encryption technology. And essentially anyone could have your public key, but your private key stays with the device or with you. And so the marrying of the public and private key is something that happens at the user location on the user’s device, not remotely on an enterprise server somewhere or a system of service you’re trying to access remotely.

And so that means that that public-private key exchange can only happen on the device that the user holds in their hands. So it breaks the ability for the adversary to capture the exchange that would normally happen when they do a man in the middle attack. And so the FIDO methodology goes a long, long, long way in removing and breaking the kill chain, meaning the cyber kill chain. Meaning if there’s no username and password to enter into a system, there’s nothing to harvest. So like a phish that says, please enter username and password breaks because there isn’t one. And so the FIDO2 Alliance or FIDO2 compliant devices, again, it’s not necessarily new standard, but it hasn’t been fully adopted. It’s not a universal adaptation, meaning the FIDO compliance gives protocols and best practices, it doesn’t dictate these. There’s no unifying body that says you must use these.

And so it relies on a, users having the capability, either a device, a biometric reader, or an authenticator capability at their end. The system or service that you’re accessing has to accept the FIDO APIs, so that’s how that certificate is exchanged with those services. And so not all web servers or web facing systems have that API capability or compliance. And so implementing what we call a password list or a passkey environment, again, it’s not foolproof based on implementation, there are some limitations. And there are some nuances to how it can be employed, some being more secure than others.

Cole French:

Just to add, I guess for the math nerds potentially out there, you’re talking about Diffie-Hellman, and like you said, it’s virtually unbreakable, the private public key exchange. And that’s because Diffie-Hellman uses exponential math using prime numbers, which in order to break would require you to reverse factor. And for those of you who may know a lot about math, reverse factoring prime numbers or derivatives of prime numbers is like Terry mentioned, basically impossible.

Terry McGraw:

With current bit lengths, right? So as we get more capable in our hardware and software, for example, the 128 encryption keys that were used for synchronous versus asynchronous. The bit count matters in this and so with algorithms like RSA, we’re talking about bit lengths that are virtually uncrackable. We say that Cole, but passwords didn’t even exist until the 60s. I mean, the idea that you could actually separate accounts on a system and allow different people to have their own accounts on a system was something that wasn’t thought of until 1968, I think. And so as we look back in history, things that we said were virtually uncrackable, I always say virtually, but that’s contemporary.

The first quantum computer that hits the street that has real capability means that now we need quantum cryptography. All the other traditional cryptography now have to be rethought. So I won’t say that this is a silver bullet, a panacea, and I won’t say that we won’t have a different discussion in five years. We probably will be having one a different one in five years. But right now for your depreciation schedule, you need to be considering how you implement this over the next 12 to 36 months.

Cole French:

Yep. Quantum computing, I was going to mention that because that’s, I think sort of the wild card in all of these. Anytime we’re talking about encryption or cryptography, quantum computing is kind of lurking on the horizon and is really going to drastically impact cryptography and encryption. Now going back to the passwordless and FIDO compliant credentials. In your estimation, what you’ve seen as far as adoption is concerned, are you seeing organizations moving to this model? Is it just kind this thing that’s out there that people don’t really know a lot about? Where do you see it in the market today?

Terry McGraw:

Yeah, it’s starting to take a lot more traction. Last two to three years, folks have really started to understand and embrace it. And there’s lots of reasons not only for credential harvesting. But damn, as a user constantly having to think of a new passphrase or password that meets the complexity and having it change every 30, 60, 90 days. If I am trying to exercise password changes between multiple websites and servers, there’s a limit to what the user is willing to feel as abuse for security, right? They’re all important things to try to achieve from a business perspective. But not only do users hate it, but every time a user resets that password, it’s an opportunity for somebody put themselves in the middle of that exchange or fake a help desk reset, et cetera. I think last year we had a huge instant response engagement where someone had just faked an employee, called into the help desk and had them reset their security information because they actually thought they were talking to a real employee.

So whenever you have that level of human annoyance, it also lends itself to human abuse. And so A, you get resistance from the user. B, it’s just a limit of human ability to retain crap. And then on the passkey, because of the way it’s implemented and that the public-private key exchange is happening at the device and at the user using something like a biometric or a PIN that’s completing the sequence, it tends to be way easier for a user. The passkeys now are way more accepted by users than they are by the enterprises to employ them. Who wants to type in to 20 character password every time they want to log into something and then do an MFA? And then if that doesn’t work, they got to go all the way back over and then if they lock themselves out, they got to call back in.

Whereas if I use the Windows Hello feature, facial recognition, biometric recognition, or a passkey that’s contained on my device, well, that’s a lot easier for users to adopt. When given comparison between traditional username password MFA versus a passkey or a FIDO2 compliant device, users overwhelmingly would choose the passkey as the authentication mechanism. So I don’t think we give users enough credit for the adoption. I would say though, that it is taking off. So the limitations are, as I said, web services have to acknowledge the FIDO2 APIs that allows that certificate exchange to happen. The actual key generation is happening at the device, and then that certificate is passed to the server, and that server then accepts the authentication. So more and more systems have to be able to leverage that sort of FIDO2 API system and so that’s a limiting factor.

Not all companies have devices that have the ability to do FIDO compliance, meaning they either don’t have a trusted platform module on the motherboards, they’re too old or they don’t have the ability to implement biometric devices or et cetera. There’s a limiting factor versus hardware. That’s why some enterprises haven’t done it. It’s a different methodology for security. So it does take time and energy to invest and change what they’ve been doing. I think all of that added a CFO probably doesn’t understand what the hell the difference is and why does my team need to change this, right? In the abstract, they understand it’s a business risk, but the nuance of why this is so fundamentally different between a password to passkey tends to get lost on a lot of the executives paying the bill.

So I think the technology has been there for at least five years now. Windows is trying to force the issue with Windows 11, meaning your TPM 2.0, you needed to have that in order to run Windows 11. Microsoft has announced that they’re going to stop supporting passwords. I don’t remember what the date they on it. So a lot of the big tech companies are trying to force us into this because A, it reduces vulnerability footprints across the architecture. And so I think that there’s a desire on a lot of the big platform companies to implement it faster than later. So I think it’ll accelerate. What I worry about, honestly, Cole, is that we will accelerate this. We’ll do it only to have quantum cryptography hit the street, and we have to rethink it all. I actually think we’re probably going to have to deal with real quantum problems in five years, but that’s five years to avoid ransomware. So I would beg companies to seriously consider this on their security and IT roadmaps within the next 12 months.

Cole French:

Yeah, I think quantum computing is also... Yeah, I think five years is fairly reasonable to expect that something’s going to come along on that front. Yeah. I share the same concern that the level of adoption is slow enough that it leaves open the door for this to kind of all be undone.

Terry McGraw:

Yeah. I will say though, I failed to mention this at the enterprise level too though, what I have seen is sort of a hybrid where a large enterprise... This is a big ask if you’ve got a global footprint with a lot of users. At least doing FIDO2 compliant devices like UB keys or cyber token for domain admin accounts. At a minimum, I recommend you do that for enterprise... If you’re looking at a tier three model, three tier model with zero one and two, have your zero and your one cyber token enabled, and that way even if something was harvested, there’s no way for an adversary to actually log into a system without the FIDO2 compliant device. That is reasonable, that is doable, that is achievable. At least you would minimize the operational damage that could be imposed on you from an adversary if you’ve locked down their ability to do real enterprise disruption by locking down your highest tiers of your enterprise management.

Cole French:

Yeah, great advice. And that goes right back to what we were talking about with conditional access, but also just thinking about it doesn’t necessarily have to be a one size fits all. Look at your environment and what’s important, what maybe isn’t as important, and you make risk-based decisions. What makes the most sense? And kind of going back to the FIDO2 compliant and how much you’re seeing that in the market, you alluded to the friction with users, right? So that got me thinking, and as we wrap up this conversation, here on the Cyber Compliance and Beyond podcast, we tend to look at things through a compliance lens. And so speak to how you think compliance helps thwart credential theft.

Terry McGraw:

Look, I would argue that compliance doesn’t necessarily make security, and having a secure environment doesn’t necessarily mean it’s compliant. The two are not mutually exclusive, but they certainly don’t have to be codependent. Why do I say that? Meaning I could implement ISO 27001 and 27002, and I could implement all of the management controls and all the policy and all the procedure. But just based on real technical implementation, it could be easily thwarted. I’ll give you an example. So let’s say we have MFA employed, so we use an impasser and we have an MFA, and a user goes to log in and they have their MFA employed. If you don’t have your multifactor authentication set up correctly, meaning that your tokens can’t be harvested by a proxy, meaning that your DNS only accepts requests into the environment from known devices, from known location, from known user, et cetera, meaning if it just takes any request and passes it on. Well then the username and token that could be harvested by something like Evilginx that then can be used in the environment.

And so compliance wise, I have MFA, I got it all in place. Does that mean I did it correctly and it can’t be bypassed? No. So it doesn’t necessarily mean that if I meet compliance, I’m more secure. The inverse of that though is in industries and vertical markets where there’s more compliance and more heavily regulated environments that demand a security compliant kind of framework, they do much better writ large in the security efficacy of controls they do have. Meaning if I’m a banking institution, I have FIEC and all the other controls around my audit inspection and I’m having to show archival evidence I’m doing these things, I probably have a higher degree of security in real terms, a real security efficacy than if I was just left to my own devices and I self attest to everything. We see non-regulated industries do far worse against cyber crime specifically, I think largely for that reason is that they’re left to their own devices to figure out where their maturity level is, et cetera.

There’s always operational trade-offs, there’s margin pressures. And so in non-regulated industries, you often see security is considered a margin hit just out of a lack of appreciation for the real existential threat it is. But I say all that to say that in highly regulated environments where compliance is inspected, the security levels tend to be better because there is that necessary inspection from an outside party, so you’re not just kind of guessing at it. But again, it doesn’t mean that just because you’re compliant, you’re going to be completely secure. You have to do things correctly, fully, and you have to have the skills and knowledge base or obtain the skills and knowledge from a third partner to implement these things correctly so that by meeting your compliance, you’re not inadvertently adding an additional seam to your security. But that’s my view on security versus compliance.

Cole French:

Yeah, I think having a third party come in, obviously you mentioned the third party assessment component, which comes with a lot of frameworks. But having a third party come in and help you with some of these things, I think is huge.

Terry McGraw:

Absolutely.

Cole French:

It’s worth the investment. Again, we go back to the whole, you could spend a little bit to have a third party come in and help you do it right, or you can spend a ton to recover from not doing it right. And then I think to close things up, I would add on to what you’re saying. I agree with everything, and I would add just that I think the importance of compliance is that it gets us thinking about these things. The biggest challenge with security is we have to think about it and we have to really put the effort into designing it, engineering it properly, right? That takes a lot of thought. And I think compliance frameworks generally speaking, help us with that, right?

Terry McGraw:

Yeah.

Cole French:

They help us remember, these are the things I need to look at and I need to make sure I configure properly.

Terry McGraw:

If you don’t know where you’re going, any role will take you there. So compliance, and don’t get me wrong, I am a big advocate of compliance for the exact reasons that you’ve said. It’s why I’m a huge advocate of CMMC. Having a framework that is well-thought-out and that illustrates use cases and examples of what right looks like, I think is incredibly beneficial for companies. Having a compliant environment also forces businesses to not make that margin call and invest appropriately in their own defense. And then the last part, and you and Andy Paul had a great podcast about the market of lemons and that this scenario that goes up around that, and it’s so true. That companies are left to figure out what right looks like and they have to guess at it.

Having the CMMC framework provides a few things. A, it gives you what to build to, what your objective levels are, how is it going to be evaluated. But it also provides a framework where ostensibly you’re getting qualified people to help you figure out what right looks like. So there’s a vetting process and a training requirement so that you’re getting qualified people to help evaluate and assess where your posture is to make sure that you’re not going to be a victim of the civil fraud act of cybercrime.

Cole French:

That is a differentiator with CMMC’s. I know there are plenty of frameworks out there on the, this is the organization it applies to and who needs to comply with it. CMMC is a little bit different in that they also have a set of standards for those who are actually outperforming those evaluations of organizations implementing who are required to comply with and implement the security controls. That is a great point. Well, Terry, thanks again for coming on and being our guest during this fascinating series. I know our listeners will find the wisdom and information you share to be invaluable as they protect their organizations from credential theft.

Terry McGraw:

Thank you again, Cole. I appreciate the invite, and I hope we reprise this in the future.