[00:40.340 --> 00:46.200] Hi there! Welcome everyone. We're here with Dylan and Allison, who presented here at DEF CON [00:46.200 --> 00:51.640] SAFEMODE on lateral movement and privilege escalation in GCP. Compromise any organization [00:51.640 --> 00:57.100] without dropping an implant. And I have to say, one of the highest theatrical production values [00:57.100 --> 01:02.240] I think I've seen so far in a video, including the hacker with the hoodie doing the whole, you know, [01:02.240 --> 01:07.940] hey, let's just pound on things, but with a real hacker. So, it was pretty entertaining to say [01:07.940 --> 01:14.360] the least. So, welcome both of you to DEF CON here at SAFEMODE. Thank you. It's great to be here. [01:14.720 --> 01:21.000] Thank you. Yeah, so first thing I want to kind of ask, just to get things started, so really, [01:21.000 --> 01:26.060] right, you like, has anything changed since the DEF CON, since you recorded your DEF CON talk [01:26.060 --> 01:31.160] and it was published? Any major changes or anything you want to share with the DEF CON community? [01:32.140 --> 01:37.560] Yeah, so there are actually a number of changes that Google's been rolling out, [01:38.420 --> 01:43.800] all of which have been super positive. Oh, it looks like Allison's video cut out. [01:44.360 --> 01:52.880] I guess she'll rejoin. I'll be answering the question though. So, I guess most notably, [01:52.880 --> 01:59.480] the service accounts or the roles and permissions which can make use of the default service account [01:59.480 --> 02:07.340] without ACT-AS are being end of life in 2021. And that was the direct response to this talk. [02:07.520 --> 02:13.540] And what that means is you will need the ACT-AS permission in addition to the other permission [02:13.540 --> 02:18.340] in order to do the action of attaching a service account to those services, [02:18.340 --> 02:22.980] even for the default service account. So, that's going to change things a little bit. [02:22.980 --> 02:28.180] In terms of what the overall security story is, I'm not 100% sure because it will lead to the [02:28.180 --> 02:34.980] proliferation of the ACT-AS permission. Ideally, folks will be applying that at the resource level [02:34.980 --> 02:40.280] for least privileged scope service accounts. But like we showed in the talk, people often apply it [02:40.280 --> 02:45.740] at the project level. So, it sort of opens the opportunity up for you to make yourself more [02:45.740 --> 02:52.160] secure, but it also kind of opens up more foot shooting opportunities. Another interesting change [02:53.100 --> 03:01.420] was that the very quick clip that I cut over to GitHub for and showed a bunch of people [03:01.420 --> 03:06.500] uploading their GCP service account credentials, I noticed that when I ran the same search on GitHub, [03:06.500 --> 03:13.180] those keys are no longer there. I assume someone went through a lot of effort to get those removed. [03:13.180 --> 03:18.160] And I was just thinking in the back of my mind, you know, they can go through that effort, [03:18.160 --> 03:25.060] they're still in that Arctic vault. So, those keys are immortalized in some capacity. [03:25.460 --> 03:30.120] But it's good that they took them down. It makes it more tricky to just immediately exploit [03:30.120 --> 03:33.240] lots of people at the gate from the talk. And I'm glad they did that. [03:34.680 --> 03:40.280] Awesome. Awesome. Yeah. So, kind of another kind of thought provoker. So, as I watch your video, [03:40.280 --> 03:44.660] I liked kind of at the beginning how you're like, here's how AWS identity access management works, [03:44.660 --> 03:49.200] right? And kind of here's the GCP model. You know, based on your experience so far, [03:49.200 --> 03:53.480] like, I guess, do you think one is better? Right? Do you prefer one model of the other? [03:53.480 --> 03:56.020] Do you think they both have their place? Kind of what's your take on that? [03:57.620 --> 04:04.280] That's a good question. There are definitely elements of the GCP platform that are unique [04:04.280 --> 04:11.180] and nice to use that AWS doesn't have. But in terms of the IAM story, I would say, [04:11.180 --> 04:15.660] generally speaking, from what I've observed, AWS more follows the principle of least privilege [04:15.660 --> 04:21.460] than GCP. And in that context, I guess it depends on your perspective. If you're a brand new [04:21.460 --> 04:25.760] developer and you want to move really quick and you want to have everything open by default, [04:27.080 --> 04:31.040] GCP is an interesting choice. If you're a security engineer and you want to follow [04:31.040 --> 04:36.640] least privilege and lock things down, AWS, from my observations, tends to do that more. [04:37.540 --> 04:40.840] So, actually, there's a question in the chat that kind of goes into that. So, [04:40.840 --> 04:48.360] go ahead and ask it. It was, for those of us with existing and sprawling GCP environments, [04:48.360 --> 04:52.980] given that the org policies aren't retroactive, what are some good approaches for tackling [04:52.980 --> 04:59.980] remediation for those deployments? That's a really good question. And [05:00.700 --> 05:05.700] I think we wanted to go into a little bit more depth into that subject in the video, but we [05:05.700 --> 05:12.800] didn't have the time to really dig into it. Remediation is really tricky. So, you can enable [05:12.800 --> 05:17.540] org policy when you're first starting an organization or later. And for all new things [05:17.540 --> 05:21.700] going forward, they'll get the benefits of it. But for all the existing projects that are already [05:21.700 --> 05:29.400] using the default service account, it's really hard to wean yourself off of it for a couple of [05:29.400 --> 05:36.060] reasons. First is that if you switch service counts on a live VM, which a lot of services [05:36.060 --> 05:41.100] are powered by, that VM needs to actually be stopped and started again to get the new service [05:41.100 --> 05:49.360] account. The second is that the default service account is kind of, like, it's not just, like, [05:49.480 --> 05:54.220] a set of permissions that's applied to your services, but it's also an IAM policy that's [05:54.220 --> 05:59.760] shared across all of your services. And so, you have two different services using the same policy. [05:59.760 --> 06:04.000] If you want to make modifications to that policy, it's going to affect both services. So, that makes [06:04.000 --> 06:08.720] it a little bit tricky. And then the way service accounts work is you can both use them as keys [06:08.720 --> 06:12.540] and you can use them as attached identities, similar to AWS. And so, you have to kind of [06:12.540 --> 06:20.660] enumerate all the different use cases and kind of systematically knock them out one at a time. [06:20.660 --> 06:24.320] So, you have to see how many keys are exported, you have to see is it attached to any instances, [06:24.320 --> 06:27.080] you have to check the stack driver logs to see whether or not they're in use. [06:28.480 --> 06:35.380] All of that can be really tricky, but some tools that do help with that are the Asset Analyzer API [06:35.380 --> 06:42.820] to see where the default service accounts are in use. And then the other one that's handy is the [06:42.820 --> 06:50.500] role recommender. So, you can get some idea of, based on the last 90-day look back period [06:50.500 --> 06:55.820] for a given project, how many permissions has the default service account actually used. [06:56.280 --> 07:01.840] Now, that's not the whole story for a number of reasons, one of which is the role recommender [07:01.840 --> 07:07.160] will only apply those recommendations sort of, you know, if the role binding is at the project [07:07.160 --> 07:10.500] level, it'll make the recommendation at the project level, it won't make the recommendation down [07:11.140 --> 07:16.480] at the resource level, and it also won't recommend that you split your IAM into two different, [07:16.480 --> 07:21.860] you know, identities, if maybe multiple services are using the default service account, it'll make [07:22.120 --> 07:26.700] a recommendation based on the summation of all those services, it won't say this service should [07:26.700 --> 07:31.440] have this scope of permissions and that service should have that scope of permissions. But it [07:31.440 --> 07:37.500] does kind of go a long way in terms of very quick remediation that you can do for looking backward [07:38.000 --> 07:40.540] for the things that work policy can't cover. [07:42.720 --> 07:48.280] Gotcha. Cool. Yeah, so I kind of had a thought too. So as I was watching this, I was like, [07:48.280 --> 07:52.240] man, this seems like a cool way for, you know, an attacker to maybe gain persistence in one of [07:52.240 --> 07:55.920] these, you know, GCP environments, like, you know, setting up an account, and, you know, [07:55.920 --> 07:59.580] maybe before some of these changes, like, hey, could you set up an account, give it privileges, [07:59.580 --> 08:03.780] and then does it just fly under the hood? I guess, what's your thought around that? Like, [08:03.780 --> 08:06.680] could you see that as a potential attack vector? Or would you see maybe other [08:06.680 --> 08:11.290] kind of attack vectors for hiding in the IAM noise of GCP? [08:12.080 --> 08:17.520] Yeah, I mean, I think a lot of what we showed is that this lateral movement, [08:17.520 --> 08:24.920] privilege escalation, persistence, it can all be done without dropping implants on a server. [08:25.200 --> 08:30.800] Like, you might for act as want to spin some things up, introduce them into the environment. [08:30.800 --> 08:37.140] For servers that have maybe endpoint software, monitoring malware and things like that, [08:37.760 --> 08:42.360] it wouldn't set those things off. So, I think it is good for persistence in that way. We'll [08:42.360 --> 08:47.300] probably need new tooling to look for these types of attacks. One of the services that Google offers [08:47.300 --> 08:55.160] to kind of help with this is the... I forget exactly what it's called, but it's a service [08:55.160 --> 09:01.060] that will monitor your Stackdriver logs and look for bad things and then alert you if it sees bad [09:01.060 --> 09:10.640] things. And so, it's watching those cloud APIs, which will be auditable. And examples of things [09:10.640 --> 09:18.100] they've used in the past are like known bad IP addresses for like crypto miners. If they ever [09:18.100 --> 09:21.160] show up in your Stackdriver logs, they'll send you an alert. But I expect these types of cloud [09:21.160 --> 09:29.180] attacks will become more and more a piece of that story. We also briefly showed a lot fishing. [09:29.180 --> 09:34.520] I think that's also a great way for persistence because if you get somebody to click an allow [09:34.520 --> 09:41.160] link on wide scope open permissions, you can get the permissions of the user without having to get [09:41.360 --> 09:47.100] a service account credential and it functions the same way. So, that's another way that you can [09:47.100 --> 09:50.080] sort of use these same techniques and get persistence. [09:50.880 --> 09:55.120] Something to note on this too is service account keys. So, if someone is able to create a service [09:55.120 --> 09:59.440] account and give it access to a resource or something, a project, that the service account [09:59.440 --> 10:06.220] keys last for 10 years. So, if they're never rotated by the organization or deleted, then [10:06.220 --> 10:15.120] you have that key for a very long time. Wow. Yeah, that's definitely interesting. [10:15.560 --> 10:23.120] Oh, another quick note on that. The long-lived exported credentials last for 10 years, [10:23.120 --> 10:30.020] like Alice mentioned, which is interesting. The short-lived instance credentials, those last, [10:30.020 --> 10:34.740] I think, closer to 10 minutes, but that'll persist after an instance is terminated. So, [10:34.740 --> 10:39.220] if you're an attacker and you're exploiting something like an SSRF or even remote code [10:39.220 --> 10:45.500] execution, grab instance credentials, even after the defensive person deletes the instance, [10:45.500 --> 10:48.120] the attacker can still persist another 10 minutes. [10:51.120 --> 10:56.400] Okay. So, we had another question pop up here in chat and kind of along with your follow-up to [10:56.400 --> 11:02.620] what you're explaining. It says, what about abandoned service accounts? Say they're deleted. [11:02.620 --> 11:07.480] Do you end up with abandoned ACLs that exist on the resources and projects? [11:09.520 --> 11:13.320] That's a good question. Allison, did you want to take that? [11:13.560 --> 11:20.380] So, there's actually something that is kind of interesting about this where we've run into some [11:20.380 --> 11:28.320] bugs, actually, where a service account has been deleted and their IAM bindings were also removed. [11:28.320 --> 11:33.340] So, if a service account is deleted, the IAM binding can still exist there. So, maybe also [11:33.340 --> 11:38.860] if you have a user in your org and you remove them from G Suite, that IAM binding will still exist [11:38.860 --> 11:46.200] in your GCP projects with user at gmail.com or whatever that is. But there's also interesting [11:46.200 --> 11:51.440] things that can happen due to the undelete capabilities for service accounts, or if you [11:51.440 --> 11:58.000] delete a service account, IAM binding, like you asked, it still exists where that IAM binding was [11:58.000 --> 12:03.380] made. And if you do, if you try to undelete your service account, you're like, oh, maybe I actually [12:03.380 --> 12:09.880] need that. And you had, or you try to create a new service account with that same name, [12:10.400 --> 12:16.100] the IAM binding will reference the UID of the service account that was, that was deleted. [12:16.100 --> 12:21.120] So, you can have this weird like caching thing happen where you'll get like permission denied [12:21.120 --> 12:26.940] errors if you're using this. So, if I create service account A and I give it an IAM binding [12:26.940 --> 12:33.160] at my project and I delete it, then I recreate a new service account, service count A, that tries [12:33.160 --> 12:38.800] to reference that existing IAM policy, it doesn't work because it's referencing the old service [12:38.800 --> 12:42.700] account that was deleted by its unique ID. So, yeah, they exist and this can bring up some really [12:42.700 --> 12:47.300] weird bugs if you're trying to create new service accounts with the same name or undelete your [12:47.300 --> 12:57.360] service accounts and you're not updating the IAM policies in parallel. Cool. Yeah, so we kind of [12:57.360 --> 13:00.760] talked about this a little bit and you mentioned this in your talk too, kind of from the defender [13:00.760 --> 13:06.880] perspective, right? Like, there's rolled out like the IAM analyzer, there's the recommender, [13:06.880 --> 13:11.400] you know, I guess, what are, are there any other things or advice you'd give to blue teams looking [13:11.400 --> 13:16.740] to secure kind of the GCP environment, right? Or the IAM offerings, like detection opportunities, [13:16.740 --> 13:20.740] like the tool you mentioned, log analysis, like, are there any, any good things to try to [13:20.740 --> 13:25.940] really dive in? Like, hey, ingest this log feed and, you know, hey, we'll see all your IAM [13:25.940 --> 13:33.600] transactions or anything like that, any advice you give? That's a good question. A lot of [13:34.660 --> 13:40.200] people will recommend that you can pipe your Stackdriver logs over to BigQuery, [13:40.540 --> 13:45.620] so that you get a structured query language that's a little bit easier to work with than [13:45.620 --> 13:53.340] the filters in Stackdriver, easier to write detection rules for and such. I think that [13:55.680 --> 14:03.840] definitely the security API that exists at the org level has some very interesting [14:03.840 --> 14:08.140] introspections that you can do across your whole fleet, and they provide some suggestions and [14:08.140 --> 14:14.320] recommendations around other types of least privilege, like buckets that were left open to [14:14.320 --> 14:18.880] the internet and things like that. There's also a lot of other org policies that we didn't cover [14:19.520 --> 14:24.100] that also will improve your security story, but just aren't necessarily related to the content [14:24.100 --> 14:33.400] we talked about, like allowing your developers to add users outside of your organization [14:33.980 --> 14:38.520] to roles inside your organization. By default, that's allowed, so you can add a random Gmail [14:38.520 --> 14:44.900] account to a project. You can disable that via org policy. So it's definitely worth checking out [14:44.900 --> 14:53.640] those high-level org policies as well. And I think that we mentioned this as well in the talk, [14:53.640 --> 15:01.200] but we had general positive experiences providing feedback to Google, and in some cases, [15:01.200 --> 15:07.140] they actually put us in touch with PMs where we could explain these issues directly to them. And [15:07.140 --> 15:13.280] so in that regard, we strongly recommend people to engage with Google around pain points and [15:13.280 --> 15:17.900] tell them what an ideal workflow would look like. And in our case, they were receptive and worked [15:17.900 --> 15:22.460] with us on those things. Yeah, I was actually going to dive a little into that too. So again, [15:22.460 --> 15:26.920] working with Google that closely, again, it's always an interesting thing when you're [15:26.920 --> 15:32.540] approaching someone with base-level issues like that, how do they respond? Do you have any other [15:32.540 --> 15:37.460] tips for folks who'd be in similar situations, like reaching out to a Google or another company, [15:37.460 --> 15:42.620] like anything you learned out of that that you'd do better next time? Well, I think what was [15:42.620 --> 15:48.200] interesting is there's kind of two ways to engage with Google. There's the customer way, [15:48.200 --> 15:54.100] and then there's the vulnerability way. So you can submit to their bug bounty, and they get a very [15:54.100 --> 15:58.160] binary, this is a problem, this isn't a problem, right? If it's a problem, they'll pay you and [15:58.160 --> 16:01.700] they'll fix it. If it's not a problem, they'll close the ticket, and that's the end of the story. [16:02.200 --> 16:07.440] That's the bug bounty way. And you're interacting with the security engineer when you do that [16:07.440 --> 16:14.220] on the other end of that ticket. When you go the customer route, you're talking with a PM around [16:14.220 --> 16:20.040] them building products and giving them feedback about existing products. And that's a continuous [16:20.040 --> 16:29.160] story that doesn't end, and it's not binary. You have to sort of go through in-depth how security [16:29.160 --> 16:33.100] problems manifest themselves and things like that, which you might not have to do if you're talking [16:33.100 --> 16:40.160] to a security engineer. And you get to continue that conversation indefinitely. It's not a binary, [16:40.160 --> 16:44.760] you know, this is a problem, this isn't a problem, okay, ticket closed. So we pursued both of those [16:44.760 --> 16:58.420] paths concurrently. And I think that probably depends on your particular use case. But there [16:58.420 --> 17:03.900] were some things which we submitted as bugs through the bug bounty, and we thought that they [17:03.900 --> 17:09.080] would just be recognized as bugs and fixed. But they were actually just closed out as working [17:09.080 --> 17:14.400] as intended. And for those things, going the customer route actually proved to be more effective. [17:16.320 --> 17:21.620] Cool. That's great advice. Great advice for other people. I guess the other question I have, too, [17:21.620 --> 17:26.120] so it's kind of what's next, right? You kind of really, I guess, gone into a lot of the problems [17:26.120 --> 17:31.840] you've done a lot of improvement on this front with Google. What's your next for the research [17:31.840 --> 17:35.620] front? Are you going to continue to refine more attacks here, looking at other things, [17:35.620 --> 17:43.260] kind of what's next for the both of you? So recently, I did notice someone sent me some [17:43.260 --> 17:51.180] good resources that Rhino Security wrote up on some other GCP privilege escalation techniques, [17:51.180 --> 17:59.400] and they released some proof of concept tools. I think it would be cool if sort of the community [18:00.920 --> 18:05.760] helped bundle all of those tools into one framework. Of course, I'm selfishly hoping [18:05.760 --> 18:12.600] that's gsploit, so that we can kind of have like a metasploit for cloud. So I thought that, you [18:12.600 --> 18:19.220] know, that might be fun to consolidate some of that stuff. But beyond that, I don't have a lot [18:19.220 --> 18:24.180] of plans to do more extensive work in GCP. What about you, Allison? [18:25.180 --> 18:31.980] Yeah, for public research wise, I don't think I'll be elaborating on this topic for a while. [18:31.980 --> 18:35.920] But definitely something that I'm personally interested in learning more about and seeing [18:35.920 --> 18:42.780] the state of how different cloud providers, Google and AWS tackle IAM, because it's something that's [18:42.780 --> 18:49.120] really difficult, and I think is going to be changing very frequently for a long time, [18:49.120 --> 18:55.100] because it's such a hard problem to try to tackle. So no public research for the near future, [18:55.100 --> 18:57.240] but definitely interested in seeing what happens. [18:59.160 --> 19:03.500] And I have a question that kind of came up when I was watching your talk as well. [19:03.520 --> 19:10.560] Kind of going back to the tooling, you mentioned that you all developed a framework, gsploit. Is [19:10.560 --> 19:14.380] that something that has been or you plan on releasing anytime in the future? [19:14.800 --> 19:19.820] So yeah, it's already live. We linked to it in the talk. And you can check it out. It's [19:19.820 --> 19:24.380] on GitHub and Docker Hub. So it's just a little Docker container you can run. [19:24.680 --> 19:30.100] It was definitely released more on the proof of concept side than production code side. So [19:30.100 --> 19:36.460] some people found some bugs in it already and I'm expecting more. But it does the things that [19:37.000 --> 19:42.860] we videoed. So those demos, we can reproduce them with the tool. [19:43.520 --> 19:47.400] Cool. And then it looks like we have one more question in the chat. [19:47.760 --> 19:53.200] From your talk, I got the idea that in AWS, the account holder owns the permissions. But [19:53.200 --> 19:58.240] doesn't that cause a problem for research owners who need or want to provide permissions when the [19:58.240 --> 20:04.360] account is not under their control? I think this kind of gets at the heart of [20:04.360 --> 20:11.920] what we opened the talk with, which is whether or not your IAM model is resource-centric or [20:13.140 --> 20:19.800] user-centric. So is it basically the resource owner that controls who can access the resource? [20:19.800 --> 20:25.100] Or is it the identity owner that controls what resources that identity can access? [20:25.100 --> 20:29.560] And I think that's sort of the main difference between the two IAM stories [20:30.840 --> 20:36.840] in AWS versus GCP, at least that we opened with. We talked about some of the challenges that come [20:36.840 --> 20:43.540] up with the resource-centric model that's in GCP. We didn't really touch on the challenges [20:43.540 --> 20:52.480] of the inverse of that in AWS. And to be honest, I'm not an expert in AWS IAM by any means. [20:52.480 --> 20:55.800] And so I'd be curious to know if someone else wanted to do a deep dive on [20:55.800 --> 20:59.540] what those cons are. [21:01.980 --> 21:08.300] It also depends on how you're managing your infrastructure. It depends on are you [21:08.300 --> 21:12.160] allowing engineers to manage different infrastructure configurations, or do you [21:12.160 --> 21:17.380] have kind of a more centralized way that you're provisioning access within an account, too? [21:17.380 --> 21:18.920] Something to think about. [21:21.020 --> 21:25.780] Cool. Yeah, and I guess one thing I didn't really ask there, I don't remember, is why GCP? [21:25.800 --> 21:31.580] What kind of drew you to this area for research? Why did you look at this and the weaknesses here? [21:32.840 --> 21:41.480] Well, I think some of the defaults were definitely a little eye-opening. I guess [21:41.480 --> 21:50.380] the full story of this is someone briefly compressed down in the back of an Uber ride [21:50.380 --> 21:56.860] on my way home. I was sharing a car with someone. A bunch of crazy things in GCP that I found hard [21:56.860 --> 22:03.580] to believe. Yeah, all these things run as almost full administrator by default. And [22:05.060 --> 22:11.440] those things kind of prompted me to poke into it a little more. And then I think my poking [22:11.440 --> 22:16.520] got Allison poking, and then we just followed the rabbit hole as far as it would go. [22:18.640 --> 22:23.320] Cool. Yeah, there is one other question here that just came in the chat, too. And I don't [22:23.320 --> 22:27.800] know if you know the answer, but which model does Azure take? Is it more resource or identity-centric? [22:29.320 --> 22:35.500] Actually, not sure. I'm not familiar with Azure very much. I also wouldn't be able to speak to [22:35.500 --> 22:41.240] Oracle Cloud, IBM Cloud, or Alibaba Cloud, but I'm very curious to know the case for all of us. [22:42.240 --> 22:44.700] Future research for others to look into. [22:45.780 --> 22:46.740] Yeah, definitely. [22:47.360 --> 22:53.040] Awesome. Yeah, so we're getting near the end of our time here. But really, a couple last final [22:53.040 --> 22:58.160] ups. First, what should people look into if they're interested in learning more about the GCP [22:58.700 --> 23:01.620] identity access model? Where would you recommend someone start [23:01.620 --> 23:06.960] if they're trying to figure out how does this work, and maybe if they want to dive in themselves? [23:08.380 --> 23:14.300] Yeah, there's actually... the documentation, I think, is really great to start with. Really, [23:14.300 --> 23:19.080] just read it in its entirety. It's a lot of information. But from a hardening perspective, [23:19.080 --> 23:26.360] Google also recently released a new blog post that outlines some of the... in one place, [23:26.360 --> 23:31.280] not in each individual services, IM docs, some of the different steps you can take to [23:31.280 --> 23:35.120] harden the IM of the different services that we brought up in our talk. [23:35.720 --> 23:42.360] Oh, yeah. And on that subject, that blog post is also an answer to earlier questions of what [23:42.360 --> 23:46.920] they've done since the talk. That blog post was done in response to the talk. [23:48.840 --> 23:55.140] Awesome. Yeah, so someone said GCP is like gone cloud pwning, which seems pretty apt. [23:56.700 --> 24:01.240] But yeah, so really, I kind of opened up the last user. Anything else you really want to [24:01.240 --> 24:06.660] share with anyone? Any other last thoughts? Things that you think folks really should know [24:07.320 --> 24:09.900] about GCP before we move on? [24:12.750 --> 24:20.410] Oh, I'll just share that I am completely new to Twitter. I made a Twitter account last week, [24:20.410 --> 24:27.010] and I shared the handle in the video. But if folks want to connect with me there, [24:27.010 --> 24:31.210] and make me feel less lonely, because I don't have a lot of followers, feel free. [24:32.150 --> 24:33.850] What Twitter account is that? [24:34.490 --> 24:40.970] Oh, it's Insecure Nature. And it's linked in the talk. And I can also link in the chat. [24:43.390 --> 24:47.610] Okay, I guess my final thought would be don't trust the documentation. I know I said just read [24:47.610 --> 24:52.090] the documentation, but don't trust the documentation. When you're going and assessing [24:52.090 --> 24:57.130] things or building things, take kind of like a reverse engineering approach to analyzing things [24:57.130 --> 25:03.210] in the cloud. So test and verify the behaviors. Don't maybe just take what's in the documentation [25:03.210 --> 25:07.670] or what you think it would work, how you think something should work as the truth. [25:08.310 --> 25:12.630] Oh, yeah. And there are also a couple more privilege escalations, like I mentioned, [25:12.630 --> 25:17.850] that we just didn't have time to go into. We covered most of the ones that compromise [25:19.990 --> 25:23.550] a large set of identities. But there are privilege escalations for getting access [25:23.550 --> 25:29.410] to storage and those types of things. They're covered both in our earlier talk that we gave [25:29.410 --> 25:35.070] at BSides that I recommend folks check out. And like I mentioned, Rhino Security has done [25:35.070 --> 25:43.120] some pretty good write-ups recently on it. Awesome. Well, thank you both, Dylan and Allison. [25:43.340 --> 25:47.540] Really what I'd suggest too, if you have any particular links or summarized list of links [25:47.540 --> 25:51.560] you want to throw into the Discord chat room, that'll be helpful for everyone. There's lots [25:51.560 --> 25:57.260] of folks in there thanking you for the talk. So definitely well received by everyone here. [25:58.180 --> 26:03.100] But yeah, just want to say thank you again. Thank you for joining us for the DEF CON Safe Mode talk. [26:03.100 --> 26:07.600] Thanks for presenting in these weird times and hopefully see you in the future out in Vegas [26:07.600 --> 26:12.720] when we return. Sounds good. Thanks so much for having us. Thank you so much. [26:12.720 --> 26:17.580] Yeah, thank you. It's a pleasure. Take care. Yeah, thanks.