When your digital enterprise is everywhere, cyberattackers don’t need to scale walls or cross boundaries to breach your network. It takes just one identity – human or machine – from a sea of hundreds of thousands to get inside. It’s no wonder we have Trust Issues. Join us for candid conversations with cybersecurity leaders on the frontlines of identity security. We break down emerging threats, hard-won lessons, leadership insights and innovative approaches that are shaping the future of security.
[00:00:00.240] - David Puner
You're listening to the Trust Issues podcast. I'm David Puner, a Senior Editorial Manager at CyberArk, the global leader in identity security.
[00:00:23.590] - David Puner
As we hurtle toward the conclusion of another year, we collectively tend to look into the future, the unknown, and make predictions, calculated guesses about what's coming next based on what we know up to this present moment in time. We ask ourselves how what we know now can prepare us for how we'll respond to what's coming tomorrow. We collect data and crunch it every which way to see if there's something new or novel that's likely to emerge or if something we've seen before could resurface. And sometimes gut feeling gets sprinkled into it.
[00:00:56.940] - David Puner
Today's episode is a bit of a year-end cybersecurity fortune cookie. Its focus is an attack trend that surged in 2022; cookie hijacking or stolen cookies. There are lots of names for it, and we'll dive into what, where, when, and why in the conversation itself in a moment. What I will say here is that it's an attack trend our CyberArk Labs researchers predict will continue to flourish in 2023.
[00:01:22.560] - David Puner
To dig into the stolen cookies trend and what's coming next, today, I talk with VP of CyberArk Red Team, Shay Nahari, and Research Evangelist of CyberArk Labs, Andy Thompson. The names might sound familiar because both Shay and Andy have previously been guests on the podcast, and it's great to have them back this time together.
[00:01:40.560] - David Puner
Today's talk is based on a subject Shay and Andy have spent a considerable amount of time researching and thinking about, and it's something you should be thinking about, too, in preparing for 2023 cybersecurity challenges.
[00:01:59.910] - David Puner
You guys have been talking a lot about this recently, and there's a webinar, which we'll tell folks about at the end, that they can dive in for more information. But we're here to talk today about a trend that we're hearing a lot about, which is what makes it a trend. Cookie harvesting cookie hijacking, and as I understand it, that just means, really, the theft of cookies.
[00:02:23.440] - David Puner
So let's start with the basics. What are session cookies? Where are they located? And why are they such attractive targets for attackers? I'll shoot it over to you, Andy, just to get things rolling.
[00:02:35.090] - Andy Thompson
All right, well, that's a lot of questions right off the bat. I'll try my best here. We'll start with the origins of cookies. And this was back in 1994. A developer by the name of Lou Montulli was working at Netscape and basically created... He didn't create anything. He leveraged an old concept called the magic cookie, which allowed for credentials to be passed through a file on a Unix system, and he just applied that concept to the web browsing experience to make the session and the experience for an end user that much easier.
[00:03:15.740] - Andy Thompson
Unfortunately, that exposed a lot of risk to it, too. Essentially, cookies are... I don't want to steal it from Shay, but it's a little bit of trust that allows for the session to be established very easily. It's a collection of files that are stored on the local file system contained within a web browser, and this is the target that attackers are focusing on nowadays to really perpetuate their attacks.
[00:03:47.330] - David Puner
Why is it such a fun name? Any idea? Cookies are fun.
[00:03:53.150] - Andy Thompson
I wish I knew why the term cookie, where it came from, except for the fact that it was originated from that magic cookie concept, but I really don't know. Shay, do you know the origins of the term cookie?
[00:04:08.330] - Shay Nahari
No, I do not. Maybe just make it enticing for attackers. No, I really don't know why where the terms cookie came from.
[00:04:18.770] - David Puner
That's a good segue into the next question and I'll send it over to you, Shay. What are our few sample scenarios in which attackers could target and steal cookies to bypass MFA, without getting overly technical?
[00:04:34.940] - Shay Nahari
Right. So as Andy mentioned, basically cookies are a form of trust. They are stored in the browser. One interesting thing about cookies is because they're used by users and browsers, they don't require special privileges, so they run in the context of the user itself. The cookies are set after user usually authenticate to a certain website or use web application. So imagine your bank and you go and you use your single password, authentication, your password, and then your MFA, and then you eventually granted access to the bank. At that point, the website will set a cookie in your browser that's saying every time you authenticate for a certain period of time, you send me the cookie, and this is how I know you already authenticated.
[00:05:26.240] - Shay Nahari
For us as attackers, this is a gold mine because we now have something that would authenticate us or you to the destination. You already proved your identity to it, and it's saved with your own privileges, so we don't even need special privileges to access it. Some scenarios that we can gain access to this would be gaining access to the user computer. If you have a malware or implant running on the target, you can simply use the existing privileges and steal those cookies.
[00:05:59.950] - Shay Nahari
Another example would be if you do gain access to privileged credentials within a broader scope, let's say active directory, then you can do that at scale. You can use special privileges to just harvest all the cookies from all the users, giving you access to the entire organization, network and security. And again, the interesting part is it happens post-authentication, so it happens after the user already used their MFA, which is just icing on the cake, pun unintended.
[00:06:35.390] - David Puner
Yeah, go ahead, Andy.
[00:06:37.110] - Andy Thompson
I was just going to say that Shay makes a really, really scary point here is that this is bypassing the authentication and authorization, meaning that regardless of what MFA, brand or product that you're using, whether it be RADIUS, SAML, or even the folks that are using adaptive MFA. Once that cookie is established, it doesn't matter. You steal that, you've hijacked the session, essentially.
[00:07:03.370] - David Puner
So thinking about it then, does it render MFA useless?
[00:07:10.570] - Andy Thompson
I wouldn't say it renders it useless. Every security product out there is not infallible. There's no literal silver bullet. MFA goes great bounds in increasing one's security posture, but it's not infallible. We've seen situations like what we're discussing today in order to bypass MFA. We've seen MFA exhaustion attacks. But at the same time, it is a super strong security control. And by no means am I saying don't use MFA.
[00:07:41.680] - Shay Nahari
Yeah. And I'd like to add to that. If you think of this, you also want to consider security boundaries. What is the role of every security component here? MFA was never designed to protect against local access. MFA is designed to protect in scenarios where user's password is compromised, let's say, by credential stuffing, so if you use the same password on different attack and that credential got exposed, MFA will protect you against that.
[00:08:11.300] - Shay Nahari
The attack that we're talking about assumes certain level of access. They're basically not in the mandate of MFA. So if you have access to the computer or to the device, it's a different type of thread vectors that is just not something the MFA was designed to protect, because again, talking broader scope here.
[00:08:31.190] - David Puner
Yeah, components, I guess it makes sense.
[00:08:32.480] - Andy Thompson
Yeah, from a remote attacker perspective. A remote attacker's perspective, MFA is incredibly powerful. But like Shay said, once the machine is compromised, whether it be from a domain level or a local endpoint level, this is where the ability to hijack a cookie with no admin privileges comes into play. It's absolutely appropriate. It's just that defense-in-depth concept that we constantly advocate for, that really will make a difference.
[00:09:02.170] - David Puner
When we're looking at this, we're obviously talking from an individual standpoint, whether this happens to some regular consumer user or at the enterprise level.
[00:09:12.200] - Shay Nahari
Exactly. That's what scary. There is almost no differentiation between them. Because you could be using browser to access your personal bank, but you can also be using that same browser to access, let's say, something like Salesforce, to access your enterprise data. Fundamentally, the cookies are the same. In fact, I can tell you that because users often what we call contaminate the browser with both type of access, when attacker gain access to this, they can gain access to both personal information as well as enterprise information.
[00:09:50.910] - Andy Thompson
Yeah, I mean, think about it. With the onset of COVID-19 and our digital transformation and migration to remote work, the lines and our perimeters are essentially blurred. The perimeter of our control, where we used to have really good strong oversight of our web sessions and whatnot used to be within the containment of our corporate headquarters. Now that we're all working remotely, now that the majority of our work is being done in a web browser, this is what's making cookies resurge as a juicy, juicy target for attackers.
[00:10:28.660] - David Puner
Both of you guys have been on the podcast before. Thanks for coming back on again. Andy, you are episode number one, talking ransomware and Shay, you are episode number five, preparing for the cyber unknown, and that'll give a lot more of your backstories and background if people are interested.
[00:10:47.690] - David Puner
Shay, you had mentioned just a few minutes ago that referring to you and your team as us, as attackers. You're an adversary simulation. I assume that was a reference to that. In your respective roles, Labs and Red Team roles, that is, how do you work together when it comes to something like this? And in this case, how does your individual work come together, and how is that knowledge used to ultimately protect organizations?
[00:11:12.010] - Shay Nahari
The way we see it is basically two sides of the same coin. We look at this from same perspective in many cases, but the way we go about implementing it is a little bit different. From the Red Team side, we spend a lot of our time weaponizing and researching techniques that attackers can use, and then actually use it for our customers to allow them to test themselves against the adversary. So a lot of the way we go about this is weaponizing attacks or creating new attacks, but then allow our customers the ability to test it.
[00:11:51.790] - Shay Nahari
We don't often publish a lot of those techniques. Obviously, if there is a vulnerability that we find, we will responsibly disclose it to the vendor. But most of the research we do is around TTPs and method of attacking or weaponizing or defensive evasions. Again, things that adversaries would do.
[00:12:11.170] - David Puner
TTPs? What are TTPs?
[00:12:13.390] - Shay Nahari
Thank you. So TTPs stands for tactics, techniques and procedures. Basically everything that encompasses attackers ability to operate within the organization. But again, we focus on hands-on weaponization, defensive evasion, and what organization are likely to see when they are targeted by threat actors. I think the labs is, again, they look at the same problem and they have maybe a little bit different approach to that. And do you want to comment on that?
[00:12:44.860] - Andy Thompson
Yeah, absolutely. You teed me up perfectly. We at CyberArk Labs today definitely take a different approach to this. Albeit, we're all on the same side here. I think our research will help not only CyberArk, but everyone. We're a team of about 30 or so malware reverse engineers, vulnerability researchers, and we're looking at it more at a higher level and finding these sorts of vulnerabilities.
[00:13:13.110] - Andy Thompson
Most recently, I'm presenting the research of Mr. Zeev Ben-Porat. He did an extensive amount of research into discovering how and where credentials, including passwords, but no less cookies as well, are exposed in clear text in memory. And so really, the work that we're doing right now is highlighting his research and just showing that, again, as a standard user, you can spawn processes and read the memory of the Chrome process in order to extract credentials. And that's just one way.
[00:13:51.660] - Andy Thompson
In the presentation we'll be giving—I believe it should be on demand by the time this podcast goes live—we'll be talking about, I think, five different ways to go about harvesting secrets, cookies, and all sorts of juicy bits from web browsers.
[00:14:06.490] - Andy Thompson
But again, to take a step back, CyberArk Labs focuses on the research, responsible disclosure, that sort of things from a vulnerability perspective, whereas Shay not only does that and then some, but also executes these sorts of things as part of his TTPs.
[00:14:25.010] - Shay Nahari
Yeah, just to tell maybe two funny stories. One of the things we're trying to do as part of a methodology that we have is we don't want resources to have predisposition towards certain subject. So a lot of times, we would have people researching things on their own but don't share it in a very early stage with other people because we want other people to do the same thing and validate our assumptions.
[00:14:52.260] - Shay Nahari
Some examples that we had is, we at the Red Team, we found a certain technique to do some sort of code execution in a way that evade security product. And we were using this for customers engagement, until we, on a certain engagement, we got detected. And funny enough, a researcher in the lab at the same time thought about the same way, found a way to detect it, and implement it in our product, and that's exactly what we want to do. So we got detected by our own product and [inaudible 00:15:29] of research independently without sharing that research. And that's exactly what we want. We want to be able to come up.
[00:15:37.340] - David Puner
So spot on, Shay.
[00:15:38.320] - Shay Nahari
Yeah, we want to be able to come up with [crosstalk 00:15:39].
[00:15:39.770] - Andy Thompson
That's exactly what the Labs team is doing as well. With this particular research, we were able to develop policies that were able to be implemented within the Endpoint Privilege Manager that really allowed our product to stand out amongst the rest because our research was directly influencing the development of these sorts of features. Essentially, the research that we do enhances the features of our products and solutions.
[00:16:04.510] - David Puner
Andy, you had mentioned the webinar that you and Shay will be presenting, and that is... Do webinars drop? That's dropping on November 30th, which is a few days before this episode drops. You'll be able to find that on cyberark.com, and it's called No More Cookie for You, Attacking and Defending Credentials in Chromium-based Browsers. And there's going to be a lot more on this subject from Andy and Shay.
[00:16:32.470] - Andy Thompson
Yeah, it's on demand, so feel free to check it out and you can watch it at anytime, folks.
[00:16:35.950] - David Puner
Awesome. Why are we seeing attackers embracing this cookie harvesting, cookie hijacking approach? Why now? What's been going on? How has it emerged as a trend?
[00:16:47.610] - Shay Nahari
[00:17:06.960] - Shay Nahari
Why are we saying this? There's a few reasons. One, and probably the most important thing that is from the attacker perspective, it's a gift that keeps on giving. It happens after MFA, as we mentioned, so it bypassed the authentication that gives you constant access. And maybe more importantly, it circumvent a lot of the defensive controls that you have.
[00:17:30.230] - Shay Nahari
So imagine that you are an organization, let's say Fortune 200, and you spend a lot of time protecting your endpoint, your infrastructure, maybe your internal identities, and then an attackers get a hold of this. You can take that cookie and use it on a different machine, different side of the world, circumventing the entire control and sometimes visibility that you have. So the attacker can gain everything. You can gain access, you're basically evading the security product. You get a long-term access, and oftentimes the organizations don't even have visibility to that.
[00:18:07.340] - Shay Nahari
We've seen actors adopt it. This is not new, but we've seen a widespread adoption happening in the last maybe a year-and-a-half, two years at scale. Any thought on this on your end?
[00:18:22.640] - Andy Thompson
Yeah, I'm just waiting to jump in. Really I think it's because of the reliance on the browser as our primary vector for connectivity. Just about everything we use nowadays is no longer using dedicated thick clients or whatnot. They're using a browser to broker access, and so that's why I think cookies are becoming that much more relevant in today's society.
[00:18:47.260] - Andy Thompson
I should also mention that these cookies are easy to access, as we discussed earlier, but they're being bought and sold as a commodity on the dark web, and what we're seeing is actors like Lapsus$ and others aren't even spending the time to compromise an endpoint in order to broker access in. They're just buying it outright.
[00:19:10.580] - Andy Thompson
We saw this recently with EA Sports. Somebody was able to purchase a $10 cookie in order to impersonate someone on their Slack channel, and that's how they were able to perpetuate this social engineering attack that allowed them to do all sorts of other nasty stuff. But the point is that it was $10. They didn't have to really work that hard at it. I think that the ease of access to session cookies, the ease to steal session cookies, and our reliance on these browsers is really what's causing this to be a new resurgence when it comes to session hijacking.
[00:19:51.920] - David Puner
Interesting. So that you know of, is there any effort underway to change the way these browsers fundamentally work?
[00:20:02.390] - Shay Nahari
That's a funny question because I just had... Before joining this, I was on a conversation about this topic exactly. One of the problems in this is there are several requirements that needs to exist in the browser world. One, it is running, as we said, as the user, so you don't even need to have local admin or privileges for that.
[00:20:25.730] - Shay Nahari
Two, it needs to be simple to use and needs to cater to a lot of users' scenarios. For example, I just give one example. We know that browser can save our passwords. They give you the option to save the password. In order to be able for the user to see the password, it needs to be able to decrypt the content that he saved on his own without accounting privileges. So basically the only way of doing this is using the user's own password to the OS in order to encrypt the rest of the cookies. So those are constraints that derive from usability and need to cater to a wide range of use cases.
[00:21:05.390] - Shay Nahari
But at the same time, because you need to cater to the lowest common denominator, you need to kind of make sure that you use things that maybe are easier for attacker to get a hold of. In this case in Windows World, that enforces users of encryption algorithm called DPAPI, which is you know, it's great, but it doesn't offer a lot of the capabilities of bringing your own encryption to the table. So we see a lot of constraints driving the design decision around using those cookies.
[00:21:45.140] - David Puner
Interesting. So what can organizations do to protect against MFA bypass attacks? And is that different than what individuals, consumers, any individual might do?
[00:21:57.960] - Shay Nahari
Yes, I think we can break it down to enterprise versus individuals. First of all, again, understand what MFA can do and cannot do. The MFA, as we said before, MFA is designed to protect against the leak of a single-factor authentication password. Mostly remote. It is not designed to protect against scenarios where the attackers have access to the OS. So from individual perspective, we want to keep that in mind. We want to make sure that we understand what value it gives us.
[00:22:34.000] - Shay Nahari
One thing we haven't talked about is other form of attacks for MFA attacks. And one of the other ways is there are ability to do men in the middle or men in the browser and steal that even remotely. The same security controls that apply to phishing should be applied because there are ways to fish users against MFA.
[00:22:54.680] - Andy Thompson
And don't forget CyberArk Labs came up with this attack several years before it was first instantiated in the SolarWinds breach. But Golden SAML, if you're not familiar with this, if the SAML signing certificate server is compromised, an attacker can basically craft their own SAML certificates bypassing multifactor as well. Yeah, again, this was discovered by CyberArk Labs years before it was ever discovered being used in the wild, but there's a lot of ways to go about bypassing MFA. It's not necessarily just with cookies.
[00:23:27.980] - Shay Nahari
What I think maybe worth mentioning here is MFA fatigue. We've seen it in other attacks as well. We've seen scenarios where attackers basically keep bombarding users with MFA requests until they get tired and approved the access. So all of these obviously fall in both enterprise and individual realm. There's a lot of things you can do individually.
[00:23:54.910] - Shay Nahari
On the enterprise world, we do have EPM, endpoint protection manager, that is designed to do exactly what you just asked, designed to protect cookies in the enterprise environment. And the way we approach this is by using kernel drivers to protect the browsers themselves, the memory, and protect against injection, but also protect the location where cookies are stored. Again, everything is done at a kernel level. So even if the attacker would have gained access to a local admin, the cookies will still be protected.
[00:24:30.140] - Andy Thompson
Yes, and I learned something from talking with Shay just a couple of days ago about this DPAPI encryption. Not only are we actively protecting the endpoint with EPM, but using other CyberArk solutions, we ought to. And by all means, we absolutely are. Organizations should be focusing on protecting domain controllers as well, because this DPAPI master key, tell me a little bit more about that and share that with the audience.
[00:24:58.510] - Shay Nahari
Yeah, I don't want to go too into the weeds, but once attackers do gain access to the main admin level, they can use something called DPAPI master key, which is basically the way for the domain to decrypt any sort of DPAPI Blob in the active directory. One of those, as we said, are the cookies themselves. So if an attacker gain access to that master key, it can do that at scale. It can retrieve every user's cookies and decrypt them at scale for as long as the domain existed.
[00:25:34.570] - Andy Thompson
So let me get this straight. If the domain controller is compromised, that master key is exposed, any endpoint on that domain that has cookies, those cookies can be harvested. Is that what I'm hearing?
[00:25:49.340] - Shay Nahari
That's exactly right.
[00:25:52.490] - Andy Thompson
That takes it to a whole different scale, in my opinion. Protection at the endpoint level is absolutely critical, but potentially these cookies can be exposed in a domain controller compromise as well. That was shockingly news to me, so I'm glad that we can share that with the audience today.
[00:26:12.590] - David Puner
So as an organization or an individual user, how can you know if your cookies have been hijacked?
[00:26:21.210] - Andy Thompson
As an end user, how do you know if your cookies have been hijacked? I don't know. I mean... Go ahead, Shay.
[00:26:30.770] - Shay Nahari
Sorry, Andy. One thing you can probably do is monitor access. So whether you use password, MFA, or cookies, eventually the access will appear. So, for example, let's say Google, for example. Google does allow you to see login from certain IPs, and stealing that cookie will still show that on the log. One recommendation would be both enterprise and personal is the view locations where you seem to be accessing that service and ensure that all coming from your own known locations.
[00:27:09.890] - David Puner
I think we may have touched upon this here and there. How do attackers steal cookies?
[00:27:15.890] - Andy Thompson
How do attackers steal cookies is like multiple ways of doing it. There are, again, local attacks that could allow an attacker to read the cookies file. There are ways to extract this cookie information from memory. But there are also other ways on the server side. If a web application is vulnerable to cross site scripting, for example, this would be a method to disclose the cookie information.
[00:27:50.760] - Andy Thompson
Browsing. This very rarely happens anymore, but browsing on an unencrypted non-TLS web session could allow an attacker to sniff the web traffic and pull out the cookie information. So there's multiple ways to go about stealing cookies from an endpoint in a web session.
[00:28:14.460] - Shay Nahari
Yeah, and I can tell you what we do mostly when we do engagements. Again, this is obviously catered to the corporate world, but as Andy mentioned right, so this mostly is either access to the device so cookies are stored as a file. You just need to read that file remotely or locally and can decrypt it with the user master keys offline. So that's one.
[00:28:38.180] - Shay Nahari
And the second thing that Andy also mentioned, when we do find certain vulnerabilities that allows for client-side attack, common one would be an ability to get the client to run code if you were able to find vulnerability in the application, and that code oftentime would basically send the client cookies to us, the attackers.
[00:29:01.940] - Shay Nahari
Those are the most common one we've seen. Even the one Andy mentioned before where you can buy them on the dark web, that's basically most of the time by utilizing these two factors. Either the user machine was already compromised by malware and the attackers stole the cookies and then sold them, or they were able to exploit the vulnerability in the web server that got all the clients running or connecting to that web server to send the cookies. So those are probably the most common ways to do cookies, as we've seen.
[00:29:34.130] - Andy Thompson
When people come to me, they often ask, "Hey Andy, what do I do to protect myself from cookie harvesting and session hijacking attacks?" like what we're talking about today. And the traditional answer that we've almost always given in the infosec community is password manager and MFA. Password manager and multifactor authentication. That's the way to fix your problems.
[00:29:56.210] - Andy Thompson
Well, that's no longer the case here. If a machine is compromised with standard user access, we're able to harvest credentials, bypass multifactor authentication, and hijack these web sessions that we're now so dependent on. So the guidance that we're providing is slightly changing. Absolutely maintain that password manager. Absolutely maintain that MFA.
[00:30:20.560] - Andy Thompson
But we need some sort of endpoint control to protect these credential stores where these session tokens, these cookies, these credentials are being stored. So it's no longer just Password manager and MFA. We have to have some sort of password manager, multifactor, and some sort of endpoint control to protect these processes from stealing these session tokens and cookies.
[00:30:44.020] - David Puner
One thing I wanted to ask before we wrapped officially. I'll start with you, Shay, and the audience should know they haven't been prepared for this question. What is your favorite cookie?
[00:31:00.890] - Shay Nahari
That's a great question. It is the cookie that gave me access to the EDR.
[00:31:11.090] - Andy Thompson
You got to go straight to the technical answer there.
[00:31:13.130] - David Puner
I thought you were going to say [crosstalk 00:31:14].
[00:31:14.920] - Shay Nahari
I know, I know. That's where I fail. That's my favorite cookie. Am I right?
[00:31:19.820] - David Puner
Yup. Fair enough.
[00:31:22.000] - Andy Thompson
I could hack web sessions all day long, but when you come to real cookies, it's my wife's chocolate chips. My goodness, she makes this amazing cookie with vanilla pudding and it's so soft and so tender. Oh, my God. I'm literally salivating just thinking about my wife's chocolate chip cookies.
[00:31:39.340] - David Puner
Wow. All right, well, we'll be checking in on the IM after, see if we can get some sent up to the Newton office.
[00:31:48.210] - Andy Thompson
Hey, I'll even try to see if I can get the recipe and we can post the recipe on the podcast. What do you think?
[00:31:53.510] - David Puner
Now you're talking. I like it.
[00:31:55.300] - Shay Nahari
I'll take the cookies. I prefer the cookies themselves, so if you want to send me those cookies-
[00:32:00.210] - Andy Thompson
You got it, brother.
[00:32:02.290] - David Puner
Do you have any other predictions about attack trends in the new year? Any other old techniques that will resurface in 2023? Andy, you want to start with that one?
[00:32:13.040] - Andy Thompson
Yeah, we don't know what we don't know. With the fact that we're continuing to discover vulnerabilities and exploit those vulnerabilities, it's hard to say with any certainty what the future holds in store for us. But what I can say is that old habits die hard. The tried and true tactics of the past will continue to persist. We're going to see the continued abuse of session hijacking, the continued stealing of cookies. We're going to see more, again, reliance on web browsers, and so we're going to be seeing more and more of this sort of an attack in the future for sure.
[00:32:55.710] - David Puner
[00:32:56.620] - Shay Nahari
I can only predict things that we are doing, what we are seeing in the industry and actors doing. One major trend is the cloud-only attacks. And we see this from different reasons and something we've started doing primarily, moving away from the on premise to cloud-only. Not only doing some cloud, but moving to the operation, doing the entire attack in the cloud, and again, gives attackers different value.
[00:33:25.670] - Shay Nahari
One is the visibility. A lot of time, organizations do see the on-premise, but they lack some sensors in cloud environment. That shared responsibility model, sometimes there are gaps between what the cloud provider needs to protect versus the organization. We've seen it happens in almost every major organization we've tested. We foresee that to continue into 2023.
[00:33:52.420] - David Puner
For those people who'd be interested in diving a little bit deeper hearing more on this subject, No More Cookie for You, Attacking and Defending Credentials in Chromium-based Browsers. I guess I got to say it more like a Seinfeld episode. No more cookie for you. That is available now on CyberArk.com. Check it out. Guys, this has been great. Thank you so much for your time. Looking forward to talking to you again real soon.
[00:34:18.700] - Shay Nahari
Always a pleasure.
[00:34:19.670] - Andy Thompson
It's an honor and a pleasure. Thank you.
[00:34:20.750] - David Puner
Always a pleasure, guys.
[00:34:21.800] - Shay Nahari
[00:34:22.700] - Andy Thompson
[00:34:33.210] - David Puner
Thanks for listening to today's episode of Trust Issues. We'd love to hear from you. If you have a question, comment, constructive comment, preferably, but it's up to you or an episode suggestion, please drop us an email at email@example.com, and make sure you're following us wherever you listen to podcasts.