 Thank you all for coming. This is Hacking G Suite, the power of dark app script magic. Little bit of background on myself. I'm Matthew Bryant. You know, I go awesome by my handle, my editor. Currently lead the Red Team effort at Snap, and that's my Twitter handle. I sometimes write on my blog all that good stuff. So before we get into some of the more, you know, technical pieces of this, I just want to give some context and background to kind of help you understand what we'll be talking about and sort of some of the prerequisites here. One of them is what's called Google Workspace. Most of you probably know this as G Suite instead. Google Workspace is basically, they're like, fancy new rebranding of G Suite, but they are the exact same thing. And so what that is is just, you know, Gmail, Docs, Slides, all that good stuff together. And there's both like the public version that personal accounts use, which you're probably familiar with. And then there's like the, you know, private enterprise company version. And the only difference is really the company enterprise version has like administration and ACL policies for the company that they can administrate. And so as of the time of this research, at least, they were boosting over 2 billion users, which is quite a few. So obviously security is a pretty important point here as well. Another prerequisite to understanding this is understanding app script. So for those of you who aren't familiar, it's essentially like this really nice sort of like way to automate Google services using JavaScript that Google's created. It's like a full sort of app making suite that you can use. And they have all these like pre-made libraries that let you, you know, automate everything from like Docs, Gmail, whatever it is. And they have pre-made functions to make that super easy for you. And on top of that, they have a really nice automatic OAuth integration. So if you ever set up like an OAuth app on Google's platform, you know, you have to set up callback URLs and like authorization URIs, all that good stuff. On app scripts, when you use that, it's like kind of magic. You know, you sort of just declare the permissions you want and everything else is magically set up for you. And so you can kick off these scripts with a variety of triggers, things like, you know, on a web request, you know, kick off a script or scheduled on a cron, all that good stuff. This is an example of what the editor looks like. You can see it's like a full IDE. And it's got everything from like, you know, libraries to, you know, getting access to different services and, you know, adding triggers and all that good stuff. So for those of you who aren't familiar with the Google OAuth system, if you've used any other OAuth service provided by some other company, it's basically the same thing. You know, the core idea is your developer, you want to automate some service that people use. In this case, like all of Google services, what OAuth allows them to do essentially is they can delegate access to your third-party app so that they can go out and actually use it. So say you've got some Google docs and you want them to do some automated action on it. This allows them to basically redirect you to a permission prompt and you can say, yes, it's fine that this random app accesses my docs. And then, you know, your application gets back some tokens that can then actually use it to access Google docs on your behalf. It has over 250 scopes that you can actually allow. And this is for every single Google service under the sun. So basically anything you can think of, there's probably a scope for it, you know, GCP, Drive, whatever it is. So I talked about like an authorization prompt. This is essentially what that looks like. The idea is that it provides like sort of a human readable understanding of what they're about to grant access. So, you know, if you're some random non-technical user, you get this prompt that says like, hey, you know, example app wants to get access to your Gmail, Google Cloud, and it wants to run when you're not present. So the idea behind this is it gives them a very supposedly human readable way to understand what they're about to do. So kind of tying all these concepts together, Apps Script becomes a really attractive option when it comes to attacking G Suite, especially on like the enterprise corporate level. As well as like, it's useful for things like phishing, you know, the sort of OAW phishing attacks, as well as like, you've already have access to one account in a G Suite org and you want to like persist or backdoor access in a way beyond like, say you have a binary implant, this gives you another way to essentially persist. And what's really nice about Apps Script is supposed to sort of like the conventional, like on machine stuff that you would expect, like sort of binary command access is that even if they wipe their device, you know, as they realize they're compromised, you know, DNR steps in, they're like, oh, shoot, wipe it, you actually still maintain access past that point. They have to actually go into their Google account and like actually revoke the access for this. So, you know, even if they wipe it, you're still good. So, this is especially useful when it comes to things like sort of quote-unquote tough perimeters. So, what do I mean by that? There's kind of a growing number of companies that are getting to the point where all the fun stuff that we kind of have taken for grand over the years, things like regular credential phishing, you know, Excel macros, all that good stuff, it's kind of like slowly going away with people who have hardened environments where they have, you know, universal two-factor, you have to have hardware, you know, keys in order to actually log in. So, you know, regular credential phishing doesn't work, they may have things like Chromebooks. So, you know, binary, you know, exploitation, like a lot of stuff isn't really tenable on an average engagement, you know, attestation, all that good stuff. And so, this becomes a very attractive option when we don't have a lot of this stuff. So, to get around these measures, we're going to have to be a bit more creative. So, we'll talk first about the historical precedent here. This is a particular attack that I think I'd like to mention, which gives a little bit of, you know, a good starting point for what we're going to be talking about. So, do any of you recognize this here from a few years ago? This is a phishing email that went around for something that was later sort of unofficially dubbed the, quote, Google Docs worm. And the way that it worked essentially is you, an unsuspecting victim, would get an email like this that says, hey, your friend wants you to, like, open this Google Doc that they've made. But this is not like the standard sharing email. When you actually clicked on the open in docs button, you would get a prompt that looked something like this, right? And it says essentially, hey, you know, Google Docs, they want access to read, send, delete, and manage your email. And also, they want to be able to manage your contacts. And so, to maybe, you know, security people here, you're like, I wouldn't fall for that. Like, I know what I'm doing. But for the average, you know, user, they're like, oh, you know, Google, you know, Google Docs wants access to my Gmail. Aren't they the same thing? That seems fine. So, you know, a lot of people did that. And if you were to authorize this prompt, the very next thing that it would go and do is read your 1,000 most recent contacts. And it would then propagate itself in the same way that you received your phishing email. It would use your account to send it to all of your coworkers or your friends. And it would continue to cycle all over again, right? You can sort of remember this from some of the email campaigns of the 90s, right? Worms of that nature. But this is a more modern version. So, what is the, you know, impact of this? This actually spread extremely quickly. It affected over a million Google users. And this is not just, like, personal accounts. This is, like, enterprise users on, like, corporate networks. This is, like, you know, average, you know, everybody, you know, your friends or whatever. And so it affects, like, both sides of the fence. And while Google responded, like, pretty rapidly, like, they realized this is a really bad deal, it still took them a couple hours to fix it. And even in that time, we saw this rapid spread, right? So, more analysis essentially indicated that this was not an APT-style attack. It was actually pretty amateur for the most part. A lot of the code was copied from, like, Stack Overflow. So it actually could have been a lot worse. So breaking down some of these attack components, we have some, you know, advanced traits, things like they had multiple rotating, like, domains and, you know, OAuth IDs that they had created to sort of make it hard for Google to go and block them. You know, if they had one domain or one app, Google would just be like, oh, okay, we'll block this app and we'll block this domain and then these attack is over. So they actually did this. They wrote, they had multiple, you know, IDs and domains to get around this, which convocated the remediation effort, which is fairly advanced. They had what's called an IDM homograph attack in the app name. That is just to say that, you know, you saw previously, they had the word, like, hey, Google Docs is requesting this permission. One of those characters is actually a Unicode character, you know, like, say, the Swedish O or something, right? And it looks exactly like it's, you know, U.S. equivalent, but to the, you know, it's not the exact word, so it gets passed like a basic filter that prevents them from setting a name. It looks like an actual Google service. In addition, you know, we saw this already. It uses some clever social engineering tactics, right? It comes with this, like, sort of clever pretext about your friend sending you Google Doc, which you pretty expect, and that holds greatly with the spread. So, unsurprisingly, after, you know, this thing spread, a lot of people and a lot of companies were like, this is really bad. I want to prevent this from happening in the future. You know, what can, like, they demanded a lot of change and how sort of the OAW system worked at Google and some changes to help or, like, companies protect themselves. So, around two months later, Google basically introduced something for sort of the G Suite administrators, so you can think of, like, people that run G Suite at companies protecting their employees, and this protection essentially allowed them to say, like, okay, all the employees in my company, they can only authorize specific apps for permissions on their account, and I have to explicitly say what those are. So, you can say, like, I have 10 apps that I trust, none of my employees outside of those 10 apps can authorize access to their, you know, Gmail, Drive, whatever it is. And so, in addition to this, they also cracked down heavily on usage of what are called scopes, right, those permissions I mentioned earlier, like, access to Drive, Docs, whatever it is, and they put basically these new categories in place. And so, how this works is essentially, if you're trying to access something that's a sensitive quote-on-quote scope, you have to go through, like, some intense review, and there's more warnings that get shown to you, such as the quote-on-quote unverified app warning. And we'll see an example of that in a little bit here. And as well as that, they, you know, did a crack down on all the misleading OAuth apps to try to make their ecosystem a little bit more, you know, cleaned out. Some quick food for thought here. You know, we saw the previous attack, you saw the impact, right? But it didn't have any crazy zero days that we would normally associate with a hugely successful worm, right? You normally expect, like, some crazy zero day in an e-mail client or, you know, something like that before you see, you know, attacks succeed at this level. But this really didn't utilize a lot of those. Apart from the Unicode trickery, there wasn't anything super special like that. But the impact was still substantial. So that's something that I'd like to point out is sort of one of the central themes of the talk is that you don't necessarily need crazy zero days to pull off big attacks, sometimes just understanding the systemic issues of the platform. It's more than enough to pull off stuff like this. So we talked about some of the stuff that they've added, but let's talk about sort of in the modern day, with all these new protections, you know, what can we do still as attackers? I mentioned before we had the unverified app prompt. This is what that looks like. I know many of you sort of think, oh, prompt, maybe a user will just click past it, right? A lot of users are annoyed by computers constantly telling them what they can't do. I want this e-mail right now and I click past things. This is quite a more heavy handed system. So they take some lessons, I think, from Chrome's SSL warnings, where the user has to click through, not like basically tiny text to show more advanced options, then actually click like, you know, I actually really, really do want to go through before they can even get to the allow permission prompt. So this is actually like a significant hurdle for us as attackers. If we send this to a victim, they are, you know, if there are, you know, not a super strong technical user, they may not be able to get past the prompt at all. They may be like, I don't know what I'm doing here. So I mentioned previously sensitive and restricted scopes, right? And this is basically any permission which has access to private, you know, user data or something like that, right? So you can imagine for most Google services that applies. And so naturally this means it's like over 120 APIs fall under this kind of like, you know, cloak of like sensitive or restricted. So the way that this works essentially is if these scopes fall under this category and your app requests them from a user, now if your app has less than 100 users, you'll get that unverified prompt I showed you before, which is going to be very hard for users to click through. If they have more than 100 users, it's actually even more strict. So you actually have to go through a manual review process done by Google. And that is such a stringent review process that even people who legitimately want the access, they, you know, have trouble getting it. So companies whose entire app is built around one piece functionality, they've even written posts and playing like it's very hard to get past this approval process. So that's not likely a tenable route for us, right? But there are some exceptions. So if you read the documentation for this, they say like, okay, when does this unverified prompt occur? And they have sort of this table which you don't have to read through. But essentially if you look at the intersection of these two points, this is what you're interested in. And so the way that this works, essentially, is if your app requests one of these quote-unquote sensitive scopes, if the person who creates this app, it's the publisher of the app itself, and the user who is then authorizing this app's access to their own account, if they're in the same G Suite domain, the prompt isn't shown. And you can think about this like, you know, logically speaking, you're like, okay, you know, if my coworker makes an app and they, you know, to automate something internally , do we really need the same level of strictness, right? Do we need the unverified app prompt? This internal thing, we're all kind of trusted here, right? So that's kind of the logic behind this. So another thing to note about Apps Script is it doesn't have to be its own script. It can actually be attached to what's called a container. And what that means is essentially it's just some Apps Script that's attached to a doc or slides or, you know, Google Sheet or something like that. And it basically modifies the Sheet to the doc or whatever, you know, and it can trigger it when people like open the doc, for example. And so the way this works essentially is if you have some Apps Script, say, attached to a Google doc and you send it to somebody else, you have to essentially share editor access to the doc in order for them to be able to, you know, execute the Apps Script attached to it. But otherwise it works in very much the same way as the regular Apps Script. So if we have a general attacker, we're trying to attack an organization, you know, we have to first grant them editor access to the doc. We attach some Apps Script and we send it to our, you know, victim who's inside of this org that we're trying to compromise and they open it. But, you know, like I said, they'll normally get this, you know, hey, this happens in Verified. Are you sure you want to do it? You know, do some magic clicks to get around this. So it's likely to fail because the user is probably familiar with it. Another very interesting trick that you can perform is when you have sort of like your Google Sheet or doc or slides link normally ends in that little forward slash edit that you're probably familiar with. But that's actually not the only, you know, suffix that you can have. You can actually change it to copy instead. And when you send a link with copy at the end to the doc, the user will instead get this prompt instead of, you know, opening to the regular edit menu that you're trying to do. And then you can do that. You can also do that by sending a copy of quote confidential org-wide Confim Promote Details, something that I, the victim, very knows you would love to know. And when they click this make a copy button, essentially what this will do is it will copy it into their drive and then they will immediately take them to the edit dialog. So like it makes a copy into their own drive and then they immediately can do that. Now when they go and they actually activate the trigger and this spawns this access request prompt, suddenly we're not getting that warning that we were talking about previously. But why exactly is that? And so if we examine the actual permission prompt a bit more closely, we can actually find the answer. So if you look at who the developer is in this little prompt, you find out that the developer is actually the victim themselves. And so wait a minute, the reason is because when they actually do the click make a copy button, it actually copies the document into their own Google Drive and when it does that they become the creator, right? Because they copy the document, they put it in their own drive, they are now the owner and so you basically, they are now the creator of not just the document but also the script attached itself. And so the person who's requesting the permission from the victim is the victim themselves and they're both in the same G Suite org that we were talking about before. And so this is what bypasses that check. But we have a problem. So if we do this copy, we run into this situation where if we have triggers that are attached to our document that we're supposed to run, the triggers don't get copied over which is kind of annoying. So now we need the victim to be able to trigger our script so that we can actually get this prompt to show up. But the triggers aren't being copied. So what should we do? So one of the useful ways to do this is to trigger what are called macros. You can sort of think of this as like Google's version of the classic Excel, you know, VB script style stuff. And what this does is essentially you can declare macros which allow you to basically call arbitrary app script in the background. And what's more useful is you can actually have a macro where you can take an image or some other item and when they click on that it will actually trigger the macro to actually trigger your payload and it will also survive copying. Here's a quick proof of concept video showing this. We see the victim, they click, you know, make a copy of this Google Sheets and when they do this it again gets copied into their Google Drive. They immediately come to the edit menu and they get this very trustable goose picture. You know, they go to click on it and when they do they get an authorization required prompt and when they click to that they see that they're done. So, that's actually not all that we've bypassed with using this technique. It's actually even better. So, recall I mentioned previously Google also introduced the protection which says, hey, you know, G Suite administrators, now you can basically limit what permissions your employees can delegate to third-party apps to only a specific list of apps that you trust. Well, this actually also gets past that check as well because this is quote, like third-party app protection whereas this isn't third-party, it's owned by the victim. So, again, it's internal and it bypasses that check as well. So, in doing this we bypass both the unverified app prompts and the other internal administrative restriction, right. So, again, back to square one without these protections enabled. So, another even more fun tip for defeating sort of these two protections that I mentioned is when you have, you know, a Google doc and you have some Ascript attached to it, one of the things you sort of ask yourself is like, okay, so if I own a, if I create a Google doc, am I the owner and creator of the script attached to it? And the answer to that is yes. You're the owner and creator of both. So, now we run into an interesting situation where if somebody creates a doc, you know, inside of a private G Suite domain and they share edit access with somebody outside of the organization, that person can basically not only edit the document itself, but they can go and they can add an Apps Script too. And when they add that Apps Script, this Apps Script that's added is not run as the person who just made this edit, it's as the original owner. So, if you can find any publicly facing like documents or sheets or whatever on, you know, Google on G Suite, you can actually add Apps Script into them and bypass all of these checks as well. So, once you're actually on the inside, now we want to like sort of like, you know, we want to pivot around, we want to ask go to privileges, all that good stuff. How can we go about doing that? So, likely one place that you're all interested in once you've made your initial compromises, probably the good stuff is potentially in Google Cloud, right? If they're on top of G Suite, they probably use Google Cloud as well. They're all in on Google and so, you know, they're probably out as well, they're all in on Google and so, you want to head there and get where the good data is, right? If it's a tech company, that's where their servers are, that's where the databases are, that's where all the fun is. So, can we actually access, can we fish access to Google Cloud through Apps Script? The answer is yes, but it's not so obvious. So, there is a scope, essentially for, you know, what's called the cloud platform scope. You can see that has this tiny little thing here, like the description of it, which isn't super alarming. And essentially, if you authorize this scope, it means, like, wide access to Google Cloud. Any Google Cloud service, you have full access to it on behalf of the user, so you can basically go in as the victim and access all the projects and, you know, various resources they have access to. And what you can do is, you can basically use what's called the script app that get OAuth token function call. And the token that's returned by that, authorization bearer header, and you can use that to make any, you know, sort of API request to all of the various Google Cloud APIs. However, when you do this, you're going to quickly notice something that's a bit weird. So, when you issue an API request with this token and the authorization bearer header, you're going to get this error back that's going to confuse you. So, in this case, we're trying to access the IAM API, and we get this reader that says, hey, you know, this API has not been in the project before, so it's not enabled, or perhaps somebody disabled it. What's even more perplexing is the ID number for the project. It's probably not going to be the one that you're actually requesting. It's some other one that you don't even know what it is. So, you know, what the hell's going on here? So, this is not super documented, but actually whenever you create a new app script project, you are actually invisibly creating an entire Google Cloud project behind the scenes. And inside of a Google domain, this is actually an internal Google Cloud project that's created. And this is magically bound to your project. So, when you make API requests, this essentially is like automatically, your app script project is bound to this Google Cloud project. And so, your request will essentially assume that you mean in the context of this Google Cloud project, and that's why you're getting that error we saw before. The product number is actually for the special hidden one that's actually available to you that was created when you created your app script project. So, that's annoying. How can we get around this? Well, it turns out you can specify what's called the x-google-user-project-header followed by whatever, you know, the internal Google Cloud project that you want to access is. And this will allow you to essentially, you know, bypass this protection. Or, not protection, sorry, this is like weird functionality. So, we see an API request over here where we're going to access a specific product ID. Not only do we specify the authorization bearer headers, but we also specify this, you know, project header I mentioned before. We specify the project ID we're trying to access, and this will succeed as expected, right? So, you can use this to pivot totally inside of Google Cloud and get access to all the stuff that you're expecting, right? So, anything your user has access to, you now have access to as well. If the data you're looking for is not in Google Cloud, it's probably in Google Drive, because, you know, say you're not like a tech company that has servers and software and all this stuff running in Google Cloud, maybe you're a finance company, it's probably in Google Drive instead. So, how can we get access to that stuff? So, we'll take a moment to talk about sharing in Google Drive, which is sort of a unique ACL system. There's essentially sort of three levels that you can do when it comes to sharing items in Google Drive, and so the most restricted version is essentially, you know, what's quote-unquote restricted. This means like, you know, you have to individually add every single user that needs access to this item, and, you know, everybody who's not on the six-plus list can't access it. The next level, you're probably familiar with essentially, it's shared by link, so only if you actually already have the link or have knowledge of the link, can you access it, otherwise you can't find it. So that means like, internally in an org, if somebody's like searching in the Google Drive search bar, it won't come up, it won't be indexed for them, unless they've already viewed the doc once. And then there's actually even a wider setting that you can do where you can say, not only if they have the link, but also if they're just searching and they can find it. But that requires a few extra clicks. So, you know, sort of by default in this world, you know, you're essentially sharing with the entire organization by link alone is just one click away. And sharing a searchable version is essentially two clicks away. And like I mentioned before, they view it once and searchable in the future. And unfortunately, these URLs, right, if you share by link, they're not brute-forceable. You're not going to be able to just like, you know, break away the entropy if you have to actually have it or have some way to find it, right? So, what can we do here? In the real world, this is, you know, how people use this is, you know, there's sort of like what the technical controls are and there's like, in practice, what does this actually look like? In practice, what happens like in the bulk of cases is that, you know, you say you have a byte, you know, a valuable doc or something that's important, sort of by definition, if it's, you know, it's quote-unquote important, it's going to be the one that's shared in the presentation, they're going to be sharing it with a bunch of different individuals to take a look at. And it turns out that, you know, adding one by one people to ACLs is a very tedious process. You do it for like 10 people and then you're like, okay, I can't do this anymore. Like, people are constantly requesting access. I'm like granting it. This is going to suck up my whole life. I'm just going to share it by link anyways. So in practice, share by link becomes a very, very common option for people. So how can we get access to these, you know, documents that are shared via, you know, sort of the share by link functionality? So as a starting point, of course, we can, you know, take a look at any internal systems that there are, things like chat systems, things like, you know, bug trackers, anything internally that they have to find, you know, some seed links. And that's a good starting place for sure. But, you know, a wide variety of them won't be posted there. And so one of the ways that we can find these is basically doing what we do on the web, right? When we want to find a document on the web, well, essentially the way that it works is we have these spiders which will go through all these web pages. They'll recursively crawl those links. They'll crawl them and sort of enumerate all of them. And the same, you know, sort of functionality works when it comes to Google Drive. You can go through, like, an example, Google Doc. You can pull out all the links in that Google Doc. And if they link to other documents like sheets or slides or whatever it is, you can then recursively parse those as well. And in practice, this ends up being a very useful way to find, you know, these new documents that you previously didn't know about that are shared by Link and by Proxy Find More Data. So in order to sort of exploit this functionality, I've written Apps Script Spider, which essentially, you provide it with some seed documents. It'll do exactly as I described. It'll parse through them, get links, recursively crawl them, and it will essentially dump a huge spreadsheet of all of the documents that it was able to enumerate. So this becomes a very useful thing to do when you're on Google Drive, and you don't want to take the manual time of trying to click through and find every single link in Docs. So you can find it at this repository, which I totally finished and published an hour before the talk. So take a look at that. Another useful thing when it comes to, you know, Apps Script Fishing and sort of this stuff is essentially what's called the People API. So if you're going to request some scopes that you're going to fish out of your user and sort of a lesser known feature of G Suite, and the way this works essentially is G Suite by default sort of comes with this like really nice internal employee directory. And this allows you to actually enumerate all of the other people working, you know, at your quote-unquote company inside of your G Suite domain, and it has things like their email address, you know, their sometimes more details like their titles, stuff like that. And it becomes a very useful thing to, you know, snag a quick copy of it and say essentially take this and say you get pulled out like DNR comes in and they say, what is this, you know, this malicious app revokes it from their account. If you get a copy of this, you actually have a very useful resource for saying, okay, I want to do another spear fishing attack, but now I have all the org structure and I can use this to perform a much better version of that, right? You know, who works in finance or HR or whoever it is, right? Let's talk about, you know, privilege escalation, right? So we talked about sort of like digging up stuff, enumeration, pivoting around. Let's talk about increasing our privilege level. So we're going to remember what I talked about a little bit earlier, where you can have essentially Google Docs and Sheets and you have Apps Script that's actually attached to them. We're going to sort of look into how this actually works, right? So remember I mentioned they could be bound, how does it work exactly? If you have a Google Doc and it has the actual Google Doc itself and the script is attached to it, like do they have the same ACLs? Like if I share edit access to Google Doc, does the script attach to it? Is it also editable by whoever I shared it with? Is that a separate ACL? How does that work, right? So again, if you go to the useful docs, you'll see that actually there is no difference in the ACLs between them. Anybody who is an editor of a doc is also the editor of the script attached to the doc. There's no distinction. Which is, you know, a much more simple system. But this brings up another question, right? Because remember, if I want somebody to actually trigger my Apps Script, if I want to make my Apps Script usable in any way, I have to give them edit access to do that. So this creates a very interesting problem, right? Say I make an internal Apps Script app, I make it for my coworkers to automate their lives. Now, in our firm to actually use it, I have to make them editors of the document, or, you know, Sheet or whatever it is, but now they have access to the script as well. And that doesn't really sound great, right? How does that work? So we can imagine the situation, right? You have, say, a Google Doc with some script. You share with your coworkers so they can automate their, you know, Google Cloud or Docs, whatever it is. But a malicious user also has added access to the doc. They can come in, and they can edit the script attached to the doc to be, you know, arbitrary. They can add some extra special code in the middle of the script. They can send me an access token for that user, you know, pump all the docs out, whatever it is. And then when the other users come in and they invoke the trigger as a part of the regular, you know, sort of usage of this, when they do that, they will run the attacker's malicious script, and the attacker will be able to execute, you know, the script as them with other permissions, whatever permissions were requested by this app, right? So not great. But, you know, as attackers, they can do whatever they want to do or what I'm doing, right? I don't want to say, like, well, I'll wait until they use this random internal app again, and then I'll compromise them. I want to, like, do a script as them now. So there's actually a way to do one better. So it turns out that we can actually force them to re-trigger the script by using what's called Web Endpoints. And so you can actually, like, publish the app script trigger as a web endpoint that is, like, essentially automatically triggers the script as them, and it will run with their permissions and the scopes requested by the app. But it's actually even better. If they don't have to visit the link directly, they can visit any web page that links to it with, like, an image tag or style sheets, and that, you know, sub-resource trigger works just as well. So they can send them to any web page that includes this image, for example, and that will automatically trigger it with their, you know, permissions as tough as you can use this to immediately re-trigger your script. So you do that, essentially, is under the app script editor. You do a new deployment. You select the web app type. You deploy it just like this. And you get this URL back. And essentially this is the URL you can use inside of your image tags or whatever else it is to get, you know, your victims to run it again. Cool. So let's talk about some more lateral movement techniques. Some of you are probably familiar with what's called Google Groups. So Google Groups is often promoted, not just as a way to say, hey, here's how to create an email list that you can, you know, email like these people and get the same group of people. But they're often promoted as a very useful ACL system. So they say, hey, you want to gain access to a doc or some Google Cloud resources, just create a Google Group. And you just add the appropriate users. And when you do that, you can basically, you know, have a good gating functionality to build these ACL policies, right? But there is one issue in G Suite by default. All created Google Groups are sort of open by default. So when you create one, anybody internally can find this Google Group via search and they can just join it without any sort of problem. You have to actually go in and implicitly lock it down and say, no, people can't join it, people can't do this, right? So on their own, that's not terrible, but together it's really not great, right? Because now the default for every single person that wants to use this as an ACL, they're now going to create a vulnerability, right? Unless they explicitly take extra steps, not do. And we know that when the default is pad in practice, many, many vulnerabilities get created, right? It ends up being sort of an endless privilege escalation factory. And so this is very useful to us as attackers when we're trying to sort of improve our permissions. So, you know, okay, it's an ACL system, but what's actually gated by this? It's gated by, you can use it to gait Google Cloud, you can use it to gait all the stuff in Google Drive, you can make even admin, G Suite admin policies that are gated by Google Groups, calendar, you can even polish in Chrome extensions can be gated via Google Groups. So the possibilities are actually quite endless. So I'm going to make a quick distinction here. There's some functionality that's available on the API level versus sort of if you have the full account, you're going to click around manually in the account. And so like for Apps Script, for example, we don't have, you know, we have access via the API. So I'm going to talk about some stuff that's accessible only via the API. So when you see that, think like, okay, my implant can do this. And the other stuff, you think, okay, I actually have a login access to this account and this is what I can do. So what can we actually access, like say if we have an implant in Apps Script, right? When it comes to Google Groups, modifying it is not as easy as it sounds. The actual API is restricted to sort of explicitly stuff created by Google Groups. But there's something called the Google Cloud Identity API, which by proxy allows you to sort of edit Google Groups via the API. So what can you do via this API? You can list all the Google Groups in organization, you can list all their members, what roles they are, and you can also create and manage and update your own Google Groups. But sadly one of the things you can't do is you can't join open Google Groups via the implant, which is very sad because you know of course if you have the full level access to the account you would be able to do that. Cool, so we talked about internal privilege escalation, we talked about getting into perimeter, all that good stuff pivoting around, let's talk about sort of like back-drying stuff, stealth and persistence. So we're going to some interesting Gmail trickery that's useful. When you have API access to Gmail, one of the useful things that you're probably going to immediately want to do is you're going to be able to do the same thing. So this is an incredibly useful tool for email, which will allow you to essentially say, hey, here's a matching rule, if an email matches this format, in this example it's like no reply to accounts like Google.com and it has a subject security alert, just throw that in the trash, throw that in their all mail, don't show it to the user. So you can essentially use this to hide all of these sort of warnings that you're going to be able to do. So we're going to use this to hide all of your email accounts. We'll get rid of that. On top of that, people's email accounts tend to be the center of their world. All of their random internet accounts, they use their email addresses, their centralized source of trust. So if you have access to their email, you can do a password reset on their accounts and gain access to their email. You can use this to actually pull the email themselves and use this to silently in the background so they take over their connected accounts. So there's another piece of functionality which is called essentially delegates and boarding addresses and this isn't available to the API, sadly, but it is useful to know about if you have full, you know, the login to a specific account and you want to make sure you can create what are called forwarding addresses and so these are like essentially you can create a filter that says, hey, email comes in, why don't you just take that email and forward it to my remote mailbox at attacker at yahoo.com. And it doesn't have to be a filter, it can just be every single email they've ever received and then what happens essentially is anything that matches this just gets silently sent off. And this will still allow you to essentially get sort of invisibly cc'd on all of the emails that they get going forward which can be almost as good as what you originally had. So remember we talked a little bit before about that first attack where they had this like Unicode trickery in the name. There were some protections that they changed that you can't essentially change your app name to be as deceptive as it was before. You can't just set Google Docs as the name even if you use your fancy application. So I'm going to go back to my project name to Google Docs and I try to rename it to that but when I go to the authorization prompts it's just called entitled project because Google, you know, it's like no, I know what you're trying to do, you can't name it it's something that's a Google service. So what can we do here? So as I mentioned they eliminated a lot of our regularly useful routes, no Unicode code that we changed was using what's called the right to left override character. So for those of you that aren't familiar in English when we write we write left to right but another language is they'll actually write right to left. So there's a special Unicode character that you can use and when you input that in it will actually change the position of the resulting text and so this allows you to essentially reverse the name of the app and so all the characters you type in going forward will go backwards and because of this Unicode character it will reverse it and so to the user it will look basically like it's just regular Google docs and so when you actually see I go to the prompt it says Google docs just like this initial attack did and we bypass all of this protection. Another useful thing that you're almost certainly going to want to do is you don't want one time access to an account, you want perpetual access, you want access to an account going forward, you want to use the account to snoop around, you want to be able to do this for a long time and so there's essentially this with the way they ask it works is you can essentially create these quote unquote cron jobs, these scheduled executions and those will run on a time basis allowing for background execution in the future and they can be run as often as every minute. If you read the docs though they say something very simple, they're going to declare the scope and that scope when it's actually used is going to show this extra warning prompt to the user that says hey user, this is going to run the background, do you want this to run forever? That's pretty serious. But that's what the docs say and what the docs say and what actually happens is not always the same thing. It turns out this is more of a guideline than it is a hard rule. If you programmatically create this trigger and you can not set this scope at all you can just declare one other scope and basically you can programmatically create a time trigger and that works completely fine. So it's completely unnecessary to request it and you can essentially persist indefinitely, no extra warnings and have access to the account going forward. So always test to see if the difference between what said is true and what actually is the case because you'll find a lot of very interesting stuff that way. And that's it for today. Thank you and we'll see you in the talk.