Cracking Hidden Identities: Understanding the Threat Surface of Hidden Identities and Protecting them Against Password Exposure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the Verizon DBIR is that most usage of AI is done with either incognito or personal accounts. A part of that in my estimation and that's not data driven. It's just personal impression. The fact that a lot of graduates in the last couple of years were trained in universities in college to use AI. They already have prompts that are used to they have all kinds of templates. So they do like to use that within their familiar environment turning chat into their personal assistant basically and that relates to uh how they're being used within the work environment and then let alone AI security it's it's on the identity level it's not a work application it's something entirely

different and then comes the question in real life how does the iceberg looks like for each organization now I gave some statistics the v variance between organizations is huge um some of those problems even scale over time and scale with size. So I don't have to check but any successful business in in in the United States that's growing and has an M&A activity they run someone is running about hundreds or thousands of domain names. Each one of those domain names may have all kinds of identity services. Each domain name and each account can be under a couple of uh provisioning solutions. Some users are chaining their uh entra identity to a Salesforce identity to a GitHub identity and there

is some sort of a chaining. It's really really hard to track over time and then you got all kinds of loose ends within that. For example, um what happens when there is no login or some sort of a QR code? What happens when it it is connected to some sort of a a password, but the but the password is behind a password manager? Many users at work actually connect passwords of work to their personal password manager that syncs passwords to another device. We talked about old domains, temporary accounts. Um if anyone of you ever you know filled in a security questionnaire they're all done using temporary accounts um and a thirdparty accounts. So uh most consultancy service companies

in the world need to provide access or need to get access to customers environments and are being federated to some accounts. So eventually you have my account as a company my personal account but there is a chance that I'll have a client that they have their own AI environment or their own file sharing platform they'll provision to me something that belongs to them. So I'll have ores at Gmail or at layer X and I'll have also oret at third party and all of that has effect on what's happening in the organization with regards to pretty much everything. An example for that can even be that under the same you know application on the same sign in I may you know be active on

my personal LinkedIn and my company LinkedIn. So so far we're really scared we understand that we don't really control organizations believe that they have proper visibility but the majority of what's happening within the organization is actually not really controlled or monitored and eventually we understand that there is a problem with visibility ability to assess risks and provide enforcement. Um that leads us to part number two for all those hidden identities that I go back to my to the beginning. They're not behind federation. They're not prepared for sheet storm. They all they are all vulnerable to password risks. And the the things that we believe we avoid by using uh UB keys uh certificate pinning of the device or any kind of identity

enhancements are not applicable to them. Now that brings up a question saying well I believe that in my organization users understand that corporate passwords should be more secure than personal passwords and like the question is do you really believe that users apply better reasoning in the work environment than in their day-to-day okay so with the nodding heads I will avoid doing this uh survey so what I'm about to show in the next couple of slides is based on uh a package of Dropbox called ZXCVBN which is a standard package and library to assessing password strength. Typically accounting for character types, number of characters, sequences, etc. Anything that's supposed to uh help avoiding dictionary attacks or um a

brute forcing I won't go into examples, but it's very very standard. Your bank accounts or your bank website are using them. Everyone is using this package basically. And then we all believe this table that says how long would it take to break them before we move to postquantum encryption mechanisms. And you know we want users to use strong passwords. So it would not be trivial to break them pretty much. What we found over time there is no difference in the way users are consuming passwords. Neither with regard to the strength of passwords between their personal activity and work activity but also how often do they rotate passwords. I personally experienced seeing uh accounts that the same password is being

used for over two years on a specific account and over time we see more and more you know changes usages reusage of passwords eventually bring you up to reality that if I'm an attacker and I want to get to some sort of an organization what do I do I search first of all in all kinds of dumps for user credentials I create myself some sort of a subdictionary of all those credentials that were found and then I try to reuse and resurface across all kinds of SAS environments used by employees. Eventually, it's just a matter of time and how hard would it be for me to get inside. Um, recently I hired a few folks

in the United States. All of them got some sort of a social engineering attack over mobile sending them a text that hey it's or uh I would like you to do something for me best or and all of them then sent me an email. I got an overly formal text from someone. Was it you? It doesn't sound like you. I was blessed with an inappropriate communication skills. So all my employees were able to detect that it doesn't sound like me. But eventually there is some sort of a mechanism going behind search and going Google what's an employees phone number based on new employees within the company. Actually there is a lot of automation behind the scenes and all of

that is supposed to lead eventually to the removal of an MFA or very very very elegantly to using the fact that new employees just getting their new device. So it is very very very used to the fact that they have to reset MFA multiple times. So it's just a really good really sweet point in time to get in. But the attack is already pre-made with uh credentials and dictionaries. So this is the breakdown in terms of password strength. I didn't make this chart. The color choice is horrific. H so you'll forgive me uh because it's not intuitive. But uh it shows the breakdown between passwords based on strength. When we assume that medium and below is

unapplicable also in terms of compliance. I'll let you review this for a second. But basically the differences are so so mild. It's really hard to detect. Now that's how strong is my you know my account environment. Then we have questions about the users themselves because users do stupid and stupid has a really big effect because someone will actually fall victim at some point to the social engineering attack or to that attempt to remove MFA and uh it's just a matter of time. Erh so we have those users that have credentials that were already exposed in public data breaches and we're talking about data which is significant and relevant something that could be used for social engineering. So about one of

every five corporate users has been involved in some sort of a significant data breach. About 10% had a breach that contains passwords or something that could be used. And eventually not I don't know if most but many users a big chunk are using the same passwords over decades. They don't really change so much. And um 60% 61% of users that appeared in breaches containing passwords appeared in one more than breaches uh than average. Uh so what it tries to express that their distribution between users and breaches is not equal and there is some sort of a focus area and some users that have a lot of data floating outside. Now from that point on an

attacker has to decide what to do for those shadow identities within the environment and thankfully there are all kinds of things they can do. For example uh using social engineering like many organizations are experiencing fishing and evil proxy attacks credential stuffing just using some sort of a dictionary and uh then another mechanism would be to use malware extensions to uh sneiff passwords or steal cookies in real time. So we go back to the beginning. We assume that identities are kind of like uh they enjoy an onion protection with a lot of layers. We use a strong password on top of that. MFA federation uh anomaly detection governance layers and then the attacker is pretty much starting to peel those

layers until it gets to a point in which the attacker gets close enough to the asset making it as simple as it used to be 10 years ago. And then comes the question how what where is that risk area really really focused at um we see that about only 2% of users one of 50 have a combination of they use plenty of shadow SAS in the work environment traditionally with weak passwords and they have a lot of data being exposed in in all kinds of breaches. So uh in real life what will happen is that you'll see that the same users pop up negatively on the same uh you know on the same data field. So they'll have a lot of uh

shadow SAS being used because they're not used for provisioning or god knows what they may use sticky notes on the screen to remember passwords they will use typically very weak passwords with sequences or the same password over time and because of that they are typically involved in data breaches. So the fact they use passwords is really correlated with the fact that they're involved in breaches. And I'll say that what's not apparent here that there are other aspects to identity security. For example, how often do they rotate passwords? How likely are they not to pass a security awareness test? And how likely are they to really get into a website that has some sort of a

malicious payload? And you see the same names or the same users popping up again and again. In other words, 2% of users are actually uh causing the most risk in terms of identity uh attacks and account takeovers. So, it means that if we found if we find those 2%, we're very very very likely to be able to uh reduce the tax surface significantly. Now, when I look over time at all kinds of attacks and incidents, there is a statement we weren't surprised that it was that user. um eventually I think that by the way simulations that take into account all of these aspects have a high likelihood to provide uh value and and that's you

know attackers understand that they also understand where to find and where to look for those users. Then comes the question what can we do with regard to those hidden identities to adding security to them. Um so the problem starts with visibility. Most organizations really don't have any visibility whatsoever to credential usage within the environment. It's all theoretical. Most researchers also look at this uh domain from the application standpoint. So they own an application. They see how users are consuming passwords on that application and uh we're missing all that you know hidden piece which is applications that are not managed by the organization. So visibility is is critical. Then the ability to enforce uh identity uh

practices and get some sort of a control on the identity flow and add additional security controls by assessing risk, assessing credential exposure and the likelihood of user to be within a dump is also very very critical. Um different account types have different risks associated to the organization. is actually quite significant because I'm going back to the actual problem with non-corporate accounts. Many things can happen but it's primarily the ability of a user to upload sensitive data to an unsanctioned web application or to steal data that would typically happen on a personal web application regard regardless of the fact that those apps are also targets of attackers for an account takeover. A a good example by

the way that I really recommend on reading is um I forgot the name of the company for a second. Draos Draos had an incident in which a contractor that was supposed to join the company had experienced an account takeover on his personal Gmail before joining Draos. He got the initial access to the Drago systems to his personal email. for example, access to his work email, to his personal email. A nation state was able to pick up those credentials and eventually to log in. I think it's one of the best cases of an attack leveraging a personal web application that was publicly exposed. Drios has done an amazing IR job and I really recommend reading on that.

Eventually the ways to mitigate this risk is first of all is first of all restricting the usage of nonwork SAS within the environment within the organization if not fully blocking and then restricting last mile activities on those applications as well. So checking both usage on the app as well as the way the passwords themselves are being used. Then we have the shadow SAS part the ugly the nonSSO accounts. Uh this problem is actually quite bigger than that because not all SAS supports SSO and in many cases there is a licensing problem with that regard. There are some companies that claim to solve this problem but it's it's not real because eventually uh something can sniff the

traffic, find the password or could steal a cookie. Eventually the best strategy for that is enforcing SSO on all corporate accounts and if not is really validating that passwords are being rotated quite frequently. cookies are being flushed and that the passwords are really strong. Uh using a corporate password manager would probably be one of the me most effective mechanisms here. And then for the SSO uh backed identities and all kinds of SAS and web applications, the main risk will be an advanced attacker uh using fishing, social engineering or all kinds of mechanisms to get infiltration into those applications. with this regard getting very strong controls on user activity within web websites and strong uh suite

capabilities is significant. I would mention also that we start seeing more and more uh tendency to use oath as a mechanism to collect data on users. So attackers are actually building applications that have some sort of a mechanism to login and using those credentials can actually harvest data within environments. For example, if I were to be an attacker, I would probably build some sort of a calendar app that to get data from users activity, being able to fetch where they are and use that for social engineering. There are additional uh scopes that could be used within Google Microsoft Octa environments, etc. that could allow users um that could allow attackers to fetch data on user activity um and

company data within the organization. So, I know that I actually ran over this quite fast in uh faster than I should. So, I'll get to the summary now and then open it up for Q&A. All in all, the problem of shadow identities is huge. Organizations are not even scratching the surface. Uh we see examples of all sorts. Enterprise identity and access management systems can only see the tip of the iceberg. Uh the question is really for each organization, is this a 90% security or 20% security? because that's in real life really what's happening. Some companies really do a really good job about that. In many cases, it involves a lot of manual work. For example, when it is chasing users

based on access to host names and asking them who is using that, what regard, finding the admin, taking ownership using that those manual works. Those would typically be the large financials banks. Most organizations are actually only seeing about 20% of user activity, not more than that. And the last piece of it is the network security solutions that are typically really involved with regard to mapping uh SAS shadow SAS identities don't really see how users log into the application. So uh the host name context is really it's a I wouldn't say useless but it's a it's a it's it's a bluff because eventually the way the user logs in has a lot of context. And if I go back to the slide from the

beginning, if you use a network security tool to assess this, eventually everything will be examined by the quality of the host name, the domain and not the quality of the usage by the end user and probably a network security tool will assess applications that most of them are secure, most of them are fine and actually we'll just use classification of their context. uh social media versus file sharing. Uh for example, by the way, there are like five most popular file sharing platforms. Imagine working in a company like Deote when each file sharing platform is being used across hundreds of thousands of clients worldwide and you have like hundreds of thousands of uh tenants and within each

tenant you have a lot of different kinds of identities. That's pretty much the kind of problem that companies like that experience. So I ran across this presentation quite fast. Uh I have examples and I have all kinds of stories but happy to open it up for questions now. Uh if anyone wants to ask anything

>> Hi. So you mentioned an interesting statistic there of like 1.8 users being the bulk of your risk. Um, and you also mentioned uh the fact that you were like, well, we expected that user to be the one that was popped. How do you deal with that in like a corporate context when you might not necessarily have a buyin from a user who thinks that they don't have an issue and things aren't right? So, every organization is different. That relates to a couple of things. uh how is SAS being acquired or bought within the organization and whether security is a blocker or uh or is it a showrunner or showstopper? Must I get access from security to get access to

website or not? A good example for that would be trying to go to uh product hunt and just finding a new cool tool over product hunt and trying to get access to that. Some organizations such as the big banks will just block all sites by default and allow them one by one. For companies in which websites have access that is allowed, some organizations are actually not allowing federation. So users are forced to use their personal webmail or are forced to use username and password. So companies that don't block on the network actually uh their condition gets worse. And then comes the question, how is the payment being done? So organizations that can follow the money and find the admin of the

application typically do some sort of a manual work. They review emails on um you know invoices of SAS and uh password resets trying to understand who runs what. Um in those cases they'll just find the admin and try to get access to that uh admin. Most organizations honestly don't do anything. That's like the reality. >> Hi. So um good talk. um at a former organization I worked with like you know uh so me and like all the other you know part-time teenagers got provisioned accounts uh you know Microsoft SSO but um you know we were expected to use uh you know sensitive systems that could both log in you know using SSO and personal Gmails that you

know we literally uh gave to our employer you know uh during onboarding. So how do you address like you know uh having a system secured by SSO but it's also you also have that weak point of personal login. >> So a very good example for that is developers connecting uh a company GitHub to their personal account for all reasons uh it's a problem and that like most organizations don't do anything about that. I think that the real question is whether your aim is data security or access security. So in some companies the mapping of SAS is attributed to DLP and finding where data is and that also has some sort of a lag into compliance. In some security teams

the more powerful one is who has access in terms of system intrusion that typically will lead the way with regard to where whether to allow that or not. Companies that want to secure access cannot like typically they have no solution for that or they will create some sort of a mechanism for constant validation every time. Um companies that have an aim with data security will typically try to restrict uh excilation of data uh using the browser the network. Many of them will buy some sort of a a you know a net scope or lookout some companies or cyber haven companies that have or you know or lyrics companies that have the ability to see that activity but they will

contextualize data actions with identity context. In some cases, they will just uh not actually provide significant access to data for contractors and temporary employees.

All right, I hope it was interesting a little bit that you learned something new and thank you very much.