 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 often by my hand on my editorial I currently lead the red team effort snapchat and outside of you know work I also post occasionally about security on Twitter at I am mandatory And additionally, I also do hacking write-ups and you know research posts at my website the hack the blog dot com So service office and contacts and backgrounds sort of give a base to what we'll be talking about today So Google workspace for those of you who aren't familiar essentially This is the new name that they've given to G Suite I know it can be tough to keep up with all of Google's like ever changing brand guidelines and stuff I will still be referring to this as G Suite throughout the talk Just because I think most people are more familiar with G Suite than Google workspace But you know what G Suite is essentially is it's sort of the suite of Google services that people use You know things like Gmail drive calendar, you know all that stuff This is available both for like regular users, you know, like personal individuals as well as like, you know companies enterprises and You know This allows people to sort of you know, if it's a company for example They can collaborate online to get work done using all the various Google services And at the time as of the time of this research, they were boasting like over two billion users So a ton a ton of people use this stuff So for those of you who are familiar with Apps Scripts Apps Script is essentially this like, you know, basically JavaScript language Which is used to write these serverless JavaScript apps that run on Google infrastructure And it's kind of this like custom, you know, way to build apps where it's highly, you know, optimized for automating Google services It comes with a lot of really useful libraries when it comes to like automating everything from like, you know Google Docs to Gmail to any sort of Google service you can think of And on top of having all these pre-built libraries It has, you know, it's the seamless integration with Google's app registration system and serve their OAuth system So, you know, normally when you set up like a new OAuth app with Google, you have to, you know Set up like, you know The callback URI and like configure app to work with it and all sorts of these all sorts of these things But when you use Apps Script, that's all sort of magically done for you All this authorization stuff is just sort of handled and it's sort of like automatically takes care of it So it also offers a variety of triggers that you can use to start your little scripts that you write So everything from like, you know, somebody hits a web endpoint that kicks off a script to they, you know They've opened a Google Doc and somebody's running at the beginning of that To like, you know, schedule a cron, you know, sort of like cron style things We have like scheduled execution jobs and stuff of that nature This is an example screenshot of the Apps Script editor You can see it's like actually pretty full, you know, IDE environment It has everything from, you know, code completion to like, you know, breakpoints, debugging All the stuff that you'd kind of expect from your regular dev So Google's OAuth system is very similar to a lot of the other OAuth systems out there Essentially the idea is it's a system that's built to, you know, sort of allow these like third-party apps Built by, you know, whatever individuals to request access to resources that Google users have in their account So like for example, you know, maybe I have some Google Docs in my account And I want to automate something for these Google Docs using a third-party app This allows me to basically delegate access to my Google Docs to this third-party app to do that for me, right? So these permissions to these resources, they're essentially known as scopes And there are over 250 of them And so these are for all the various Google services that you can think of, right? So everything from like, you know, BigQuery, Gmail, Google Docs, stuff like that The way that it works, right, is you sort of at your app will redirect them to an authorization prompt That gives them like a brief summary of what you're requesting permission-wise And the user can like kind of think it over and decide, yep, I'm going to allow that Or no, I'm going to reject that And if they allow it, essentially, you know, your app gets handed some tokens Which you can then use to like, you know, talk to these APIs authenticated as the user So as I mentioned that prompt earlier, this is what that looks like You have like a sort of a human readable little summary here And in this case, you know, this example app, it has, you know, hey, this is going to request access And if you allow it, it'll have access to your Gmail stuff It'll have access to Google Cloud and everything in it And also it's asking for permission to sort of run when you're not present So it's not just like a one-time thing In the future, it could just keep running, you know, indefinitely So just tying all these concepts together and thinking about things at, you know, a higher level This becomes a pretty attractive option when it comes to targeting, you know, organizations or companies that are, you know, sort of on the G Suite stack Apps Script becomes a pretty attractive option for things like phishing, you know, like targeted spear phishing as well as like you say you've already compromised, you know, an individual, you know, employee account in G Suite org It becomes a very attractive option for backdooring that account as well And the reason why it's an attractive option is because, you know, and if you have an Apps Script implant It's actually sort of outside of the eyes of like, you know, all the regular like machine monitor controls that run people's end machines and their laptops and stuff You know, so like regular antivirus, their endpoint detection tooling and sort of on-device monitoring None of that's really effective here, because again, it runs completely on Google's infrastructure It's like a total serverless environment, so they don't have any visibility into that at all And, you know, even better, you know, if your victim wipes their laptop for some reason, your implant is completely unaffected It totally remains with philaxes to their account So another thing that's interesting if you think about some of these like companies that have sort of these like extremely hardened environments Apps Script becomes an interesting option even then So what I'm talking, when I say like sort of hardened environments, what I mean is like companies with things like, you know, mandatory hardware universal two factor on logins So places where like traditional credential phishing just isn't going to work because they have a hardware key that they actually have to hit in order to like log in You know, the things like they have hardened Chromebooks, we'd like Lockdown Enterprise Policy, so you don't have things, you know, you can't get a binary implant running on there You know, you key key and then you get the Chrome extensions, potentially if they have like Lockdown Enterprise Policy And they have, you know, hardware attestation and all that other good stuff, right? So like super lockdown environments And so getting around these measures, you know, we've got to think a little bit more clever than your average attacker This isn't like the casual like, you know, Windows networking style pen tests that are potentially more common This is like a completely sort of unique environment and so we'll have to be a little bit more unique in how we think about and how we approach these things So I'm going to some historical precedent here One thing that I think is, you know, a particularly interesting example is what is the attack that happened a few years ago Which was essentially basically built around using, you know, Google's OAuth and API system Some of you may recognize this screenshot here, you know, if you were one of the individuals that was affected by this But essentially, you know, this was what was later dubbed as the Google Doc Worm So the way that this worked is it would essentially, you know, this worm would basically send these phishing emails like this You know, this would be from somebody you personally knew coming from their actual email address And it would say like, hey, you know, your friends has led you to view a document And it would give you this button to like sort of like, okay, let's open that document But when you actually went and did that, it would actually present you with this OAuth prompt here And it says like, hey, Google Docs wants to have access to read, send, delete a major email and also access all your contacts Now, you know, of course, for security people watching this, they're like, I would never approve that prompt But you know, for the average user, they're sort of like looking at this and they're like, okay, Google Docs wants access to my Gmail and contacts Yeah, I mean, I thought they would already have that, sure, why not, right? And they would probably go through and just go ahead and approve this So, you know, it's sort of like very, very convincing attack for a lot of, you know, regular computer users Of course, if they did do that and they did authorize, you know, this app to have access to their Google account What it would immediately then go do is it would use the contact access to essentially get their thousand most recent contacts You know, their emails, their friends and coworkers and stuff like that And it would send out this exact same phishing email as them to all of their friends and, you know, contacts And this would basically repeat the cycle where they would then get that phishing email that we saw before, right? The impact this attack was actually, you know, pretty impressive It ended up spreading like wildfire and essentially it actually affected over a million Google users And this is, you know, everything from like, you know, your personal Google users like you and me To sort of the big enterprise business users, you know, sort of the G Suite organizations And, you know, Google sort of rapidly responded to this actually like they had really good response time They did everything from like, you know, killed the emails that were spreading around, you know, killed off all the apps and stuff like that And they did all this in a couple hours And after doing some posts more analysis on, you know, basically the JavaScript that was used to control and run this attack It turns out the coding for it was actually like pretty amateur, right? It wasn't like this advanced crazy nation-state thing that most people assume And it, you know, essentially looked like it was only collecting email addresses So all things considered, this attack could have been, you know, much, much worse It almost seemed as if, you know, some ways that it was actually like unfinished So, you know, let's break down this attack into its kind of core components here One, you know, I would say like a fairly advanced thing trait that they did is they did think ahead and they had multiple rotating apps They registered multiple OAuth apps ahead of time and they sort of randomized them along with different domains to Essentially prevent the easy case of Google just like blocking their app or blocking a given domain, right? They had to instead track down all of the apps and all the domains and block all of them to prevent this from spreading It made use of some Unicode characters, you know, you saw it earlier, the app name was actually called Google Drive That was because they were basically evading some filters which normally prevent you from setting stuff like Google on the name of the app By using Unicode characters which look exactly the same as their ASCII equivalents So it was like Google would like maybe a Swedish O, for example And of course, you know, it used the social engineering and the phishing scheme that we saw which was, you know, quite convincing to people And it actually, you know, it's self propagated in sort of the old school email spam style, right? So it infects somebody sent to all of their contacts, you know, some of their, some of your friends end up like falling for it, you know And then they send it to all their contacts as well, except, you know, unlike the email worms of old This used for the more modern OAuth style authentication and authorization to actually carry out these attacks as opposed to like Old school credential harvesting and, you know, stuff like that So as you can imagine, this was like pretty shocking to a lot of companies, a lot of users And so Google made some pretty quick changes and mitigations after this happened Around two months later, they introduced a, you know, G Suite admin control for sort of administrators of companies to essentially lock down their orgs And the way that this would work is essentially, you know, they could publish it, they could basically set a setting that says like None of my employees are allowed to grant access to any of their Google, you know, account data for their employee account Unless it's for one of these explicit OAuth apps that I've explicitly allowed So this would allow you to lock down to prevent, you know, say this worm happened again, you know, their places straight up would not be able to grant these permissions to their account because it would be blocked Unless it was whitelisted into their, you know, under its policy And, you know, Google later introduced what are called, you know, sort of sensitive restricted scopes they basically labeled a bunch of, you know, these permissions as I mentioned before as like either sensitive or restricted depending on like the kind of data they would grant And in addition to that they introduced what's called, you know, unverified app warning prompt, firstly smaller apps that require these scopes And, you know, they went and they cracked down a lot of these other misleading OAuth apps, right, they beat up their security around like what you can name an OAuth app to prevent sort of the same exact attack we saw before so they couldn't mimic Google style names and stuff like that as well So just some quick, you know, food for thought here. This attack really didn't utilize a whole lot of like, you know, crazy zero day bugs or exploits, you know, apart from, I guess, you know, some of the Unico trickery for the name. It was basically kind of using the system as designed right, but the impact was actually like incredibly substantial right. So that's something to really think about here is like you know you don't necessarily have to have one big bug or one exploit to sort of pull off these crazy attacks, you can simply abuse the system as it was designed and design itself can just let itself to attack like this. So just something to sort of think about in general with this, the kind of those talk. So we talked about the history, let's go into like the latest right so all the will negation is in place what can we bypass and what can we do in this sort of modern age. So, you know, I talked earlier about the unverified app prompt, this is for apps of course that, you know, ask the sensitive scopes, and there's quite a few of them. So what essentially this is not like, you know, kind of a light warning, this is a really serious prompt that actually would dissuade users from continuing. It kind of takes it looks like it sort of takes some tips from like, you know, Google Chrome's like UI for like in about SSL, you know sites that you visit. And so the way that the user can actually continue is they have to like click this little Texas is like show advanced, you know, and they have to go down to the bottom and click through. And, you know, for the regular user, this is just not going to be a tenable thing, they're just not going to be able to get through this. And so it actually poses a significant barrier for us as attackers, and if we want to you know, fish a user via a lot here. So what is a you know, sensitive or restricted scope. So that just means any API with the potential to access sort of like private data. So, you know, this is everything from my Gmail, BigQuery, Google cloud drive calendar is basically it's actually a large percentage of the scope so it's over 120 APIs. And the way that works is essentially if it's a small app, if it has less than 100 users, you have this unverified app prompts. And if the app is bigger than 100 users, you need to go through an even more strict process where you undergo service intense manual review process. And this process is like no joke, like there are like companies that you have to use these scopes legitimately for like real world services that they provide. And they have written an entire post saying like, it's so hard for us to get past this review process right so it's like it's a real deal and it's definitely not something that we could really cross if we were like an attacker trying to publish which is that which is not a tenable route for us. But there are some exceptions to this policy. So if you take a look at the documentation around this, essentially, you know, if you have if it is the case where you have some apps script or an app and you use a sensitive scope, and you fall into any of these categories, then you know, either the normal off flow without the unverified app prompt will happen or the unverified off flow will happen. So one of these is particular which is the intersection of these two. And actually what this says is it says, you know, hey, if the publisher of this app is in the same G Suite org as the user who's authorizing it and running it, then there'll be no unverified app prompt. And this this sort of makes sense, right, like you can imagine, you've got an employee who's who works with you, they've created this app, and they then share it with you and you want to run it. You trust them there. It's an internal action. So it wouldn't really make sense to have this Gary prompt because it's sort of used internal and somewhat implicitly trustworthy. So that's something interesting. If we could abuse that we can essentially get around this. So one other thing to note about Apps Script is when you have an Apps Script app, it can be either a sort of standalone project, a standalone script that runs, or they can be what's called, you know, bound to a container. And by container, this means like basically you can bind it to like a Google doc or a sheet slot or a slide. And, you know, when you do this, this allows you scripting to basically, you know, you can manipulate the document, customize the UI stuff like that. And the way that works is essentially, you know, the regular triggers I talked about before, the one for any user who basically has edit access to the doc. So they have to have an access to the doc and then they can kick off any of these Apps Script triggers and sort of run this app. Keeping in mind, of course, they still have to, you know, accept the OAuth prompts if they're requesting any, you know, scopes. So if you imagine sort of our average, you know, OAuth phishing scenario, right, say we have a Google doc with some Apps Script attached to it, and we send our victim this link who's inside of this G Suite org. When they go to actually, you know, they open the doc and they trigger it and, you know, prompt spawns, they of course get the, you know, hey, Google hasn't verified this app. This question says there's scopes. And so likely the victims will be like, no, this isn't for me. I don't even know how to get through this. And so our, you know, our attempt is probably going to fail here, right. So one interesting thing about Google docs and sheets and slides and, you know, all this stuff is that if you change the average URL that you get, you know, from edit to copy. Instead of just directly opening to like this document interface, you'll actually get this prompted said. And so this essentially, you know, this prompt here says, hey, do you want to make a copy of in this case, you know, confidential or glide cop and pro or details. And they get a little bonus and say make a copy. And when they click this, what ends up happening is it copies that, you know, the document the sheet into their own Google Drive. And then they're immediately taken to the, you know, the full UI interface for, you know, working with the sheet. And so, you know, going back to the attack and mentioned earlier, so now for an attacker and we send our victim this copy link instead of the regular link. When they go to this lake, they click to make a copy of it. They'll essentially like it copies into their Google Drive. And then when they trigger, you know, the app script that's attached to it, they will get the regular prompt without this unverified app screen. And the reason why they get this is because if you if you look at the app itself, you'll notice that the actual developer behind the app is the victim. And the reason why it's the victim is because when they copied that doc, what they ended up doing was essentially they became the creator because they copied the doc there and now the creator and owner of the script. And so they'll actually see that they themselves are requesting the permission from themselves. So there is one problem though. So when you actually copy, you know, what a document with after to task to it, the triggers don't come along from the ride. So they don't really have a way to trigger this thing to get this prompt to display. So that's kind of that's kind of a pain. So one way that we can get around this problem is Google sheets have what are called macros. This is sort of something you know made to compete with like, you know, Microsoft excels like VB script style stuff to like manipulate and automate spreadsheets. But what's useful about the Google sheets version is they can call arbitrary app scripts. And what's even more useful is you can actually, if you have like an image or you know item in your Google sheets, you can assign a macro so like when somebody clicks on the image, it will automatically run this macro which you know by proxy runs any arbitrary script that you want. And so this, you know, basically is a great way to sort of like trigger your script payload. There's a demo here where you can see the victim and they go in here and they click make a copy of this of this Google sheets. And after they've clicked that button taken directly to your copied sheets and you see this beautiful image of this goose with this butter knife looking totally not threatening at all. And when they go to click on that they get the authorization prompts and when they click continue, you can see they have, you know, the regular OAuth prompt no warnings at all. So we've essentially bypassed that whole restriction around unverified apps. But that's not actually all that we've bypassed. So in addition to bypassing the unverified app, you know, screen, we've also, you know, I mentioned earlier this in a little bit earlier in the talk but that G Suite admin setting that allows you to basically like lock down your organization to prevent third party OAuth apps from requesting permissions on your employees accounts. This actually gets around that as well. So this entire system is essentially bypassed and the reason for that is exactly the same reason as the reason for bypassing the unverified app prompts, because the app is owned by, you know, it's basically when the copy into is made into the Google Drive of the, you know, the victim, they're inside the org, essentially like this makes it means that the OAuth app itself, it's instead of the new owner. It's an internal app. So it's not a third party app. It's actually first party. It's inside the org. And so this doesn't apply, you know, this block on all third party API access. It doesn't apply. So this is bypassed as well. So another, you know, fun tip for sort of defeating the both the third party app restrictions and the unfair verified app prompt is that, you know, if you go through the docs, you realize that, you know, the doc that's attached to like the app script and vice versa. They have the same owner. And so it's interesting about this is say you have somebody who's created a new Google Sheets or Docker, whatever, inside of their G Suite domain. Yeah, when they've created that that's actually kind of a bypass willing to happen, because if they share edit access with anybody outside of the organization, that person with their edit access can actually go in and they can like then create some Apps Script for that document. And the owner is still the person that created the, you know, the Docker the sheet in the first place right. So it says that sticks now you can essentially use that to start off your, you know, your phishing or whatever attempt right because that will bypass all of the third party and unverified app restrictions that we talked about previously because it will be owned by the employee that first created this document. So if you can find one of these. This is a great starting place where you can sort of skip the whole copy style attack. So we talked about how to sort of like pierce the perimeter. Now let's go into sort of like once you've got some access you maybe you compromised or we have one one employee G Suite account. Where do you go past that right what can you pivot to, you know, how can you escalate privileges. So likely, you know, most companies I'd say probably the most interesting data they have is in, you know, Google Cloud. And so pivoting to Google Cloud from your Apps Script implant seems pretty important. So access in Google Cloud through Apps Script is not super documented, but you can do it by basically requesting the scope cloud platform. And that actually gives you access to all GCP API so everything like big query to Google Cloud functions GCE, all of it, as the user who basically you know, authorizes access to, you know, to your app, right. So the way that you essentially authenticate to these API is as you use the Apps Script function script app to get a token. And you take that value to put it in the authorization bearer header, and you can use that to authenticate to all the APIs. But when you do this, there's kind of a gotcha. So you'll notice that when you try to use this for the Google, you know, GCP APIs, you're going to get this, you know, warning that says like, you know, API that you're trying to access, it's not been used in this project ID, you know, this number before, you know, either it's not been used or it's disabled. So this request is failed. What's even more strange is, you know, the product number that's displayed, it's not going to be for the product that you're even, you know, trying to access. So what's the deal with this year? Again, not super well documented, but essentially when, you know, you create a new Apps Script app upon that creation, you're allocated a sort of hidden Google call project that's immediately attached to this Apps Script app associated with it. And so what happens is like this implicitly binds your API request that you make from your, you know, access token generated by your implant with this project. So it just sort of like, that's why you have this arbitrary product number. It's for this hidden project. And you unfortunately for the hidden project, you can't like access it via the Google Cloud control panel or anything like that. You can't enable services on it. Use like programmatically like, you know, we would be able to. And so this is kind of a big problem, right? Well, it turns out that you can actually get around this by specifying the x dash Google dash user dash project header. And you simply specify the product name that you're trying to query, right? So if you're going for like, you want to modify a project example, you do this header and then set it to that value. That basically looks like this, you know, set your product ID and your API calls, set it in the header, and then you put your authorization bear header to that script, the script app that get a token value that I mentioned before. And you can, you know, go on, you can talk to all the GCB APIs to your heart's content, right? So if the data you're looking for doesn't happen to be, you know, the good stuff isn't in Google, you know, Google Cloud, then it's probably in Google Drive, right? Maybe like more financial driven companies, all their stuff is in sheets and drive. And so let's talk about sort of mining Google Drive for the good stuff. We'll begin with kind of the general overview of how sharing works in Google Drive. So by default in G Suite, there's essentially like these three permission levels. The most restricted, you know, sharing settings for a file is that, you know, only people who are explicitly as the ACL are allowed to access the document. So you just got to go one by one and add different, you know, other users and to give them access to it. If they're on the list, they cannot view the document, right? They can't access it. So the second level is, you know, anybody who has a link to the document or the file, they can access it. So essentially you're sharing by link. So if they have a link, they can access it, but if they don't, they can't, right? And then the widest, most open setting is you can even make it so that, hey, anybody who just searches inside of the Drive webpage, they can find your internal doc by doing that, right? If they're also in the company. So, you know, these are the defaults. Essentially, you know, by default, it has the strictest sharing settings where you have to explicitly add people. One click away from that. The most restricted settings is like share by link with everybody who has the link. They can access the document. And then, you know, if you do more clicks, you can get it searchable by everybody, right? And of course, you know, once somebody view, if it is shared by link, right, and somebody else views it, once they view it once, it becomes searchable in the future because, you know, the assumption is like you have a link, you should be able to find it again because you were able to visit it once. These, you know, unique document URLs are outside of the range of brute forcing. So if somebody does share by link, you're not going to be able to brute force the actual link itself. You're going to have to actually have it. So we talked about, you know, sort of like what the default and what the settings system is, but real world users tends to be quite different than sort of the strictly technical bits, right? So what actually ends up happening? So in my experience, usually what ends up happening is, you know, if a file is important, almost, almost kind of by definition, right, it's going to be shared with other people, right? Other people are going to view this document. They're going to maybe make changes, suggestions to it. And so, you know, in the strictest security setting that we mentioned previously, you know, the owner of the doc is going to have to add individual users one by one. And that's a very tedious process, especially when you have like, say you're doing it 40 people, right? That's very time consuming. And, you know, you can use Google groups to sort of like, you know, put together ACL groups that can be added in bulk together, but still very tedious process, right? So what often ends up happening is people get to a point where they're just like, they share it with so many people that they're just like, forget it, right? And they just like share by link with a large, you know, anybody who has a link, like they're good to view it. So in practice, that tends to be like pretty, pretty common, right? And only a tiny portion end up being like that wide searchable mode that we talked about before, just because of the amount of user interaction required. So how do we get access to these, you know, this big area, which is like, you know, stuff that's shared by link? So of course, there's the, there's the basic method, which is just like, I'll search all the internally shared systems inside of a company. Let's check, you know, the chat, let's check, you know, internal forums, you know, internal Q&A sites, like your ticket management queues, Dura, whatever. Bug trackers and try to mine out and look for all these, you know, Google Doc drive links. You can do that. But there's also another way to do it, which is actually the same way that we do it on the web, right? How we index and make documents searchable on the web. And so the way this works essentially is, you know, you can have a script, which will simply like take some seed, you know, Google Drive links and Google Sheets Docs links, and it will essentially like, it'll go through each one of them. So say you give a Google Sheets, it'll go through that, it'll parse it, it'll find all the links inside of that document, and it will recursively crawl all of those documents as well and look for links inside them and so forth and so on until it essentially is able to like enumerate all of these other documents, which are sort of like indirectly linked to via all these other documents, right? So I've written an Apps Script Spider that does exactly this, which you can essentially do what I just described, right? Take some seed links, plug it in. It uses a starting point and basically recursively crawls all this stuff until it's exhausted all the past and it gives you like, you know, along the way it collects like metadata about sharing, document context, the authors and stuff like that. So you can essentially like let it run, gather up all these documents and you can then like look through the results to see if it has the data that you're looking for. This is available at this GitHub link here. So feel free to take a look. Another useful thing to do is to basically request School of Access for the People API. And so what this is, is essentially like every, you know, a G Suite, it ships with this really neat ability actually to, it comes with like an internal employee directory. And so with the People API, if you request the directory.readonlyscope at a minimum, you can access, you know, you can figure out all the other employees in the G Suite org and you can get everything from like, you know, names, emails, titles, whatever it is. And this becomes extremely useful. It's something that you probably want to collect early on. So say you first compromise a G Suite employee. You want to use this like to immediately mine all this data out because say you get revoked by an administrator who catches you or they basically figure out that you did this phishing campaign, they revoke your app, delete all of your implant stuff. So having this data is very, very useful for reentry because you can make a much, much more well planned attack now that you have a good idea of their, you know, their entire organization via this API. So highly recommend this as an avenue. So let's talk about escalating your privileges, right? Let's sort of like talk about how we can increase what privileges we have and get access to more things. So one thing that is, you know, very, a very good source of privilege escalation is like legitimate internal Apps Script apps that are developed by people inside of a G Suite organization that are attached to Google Docs, Sheets, slides, stuff like that. So recall earlier we talked about Apps Script is being able to be, you know, we talked about being bound to, you know, a doc or a sheet or a slide. And this file that a script is bound to is called its container. So one of the things we have to ask ourselves is like, say you have some Apps Script that's attached to a doc, right? So in this case, do they have separate ACLs? Like, can you make it so they can only edit the script and not the doc? How does it, how does that work exactly? So if you read the Google documentation, they actually share their ACL exactly with its container, right? So Google Doc with some Apps Script attached. And, you know, somebody has edit permission on a doc, they by proxy have added permission to the script as well. So this leads to some more interesting questions, right? So you recall that edit access is required, as I mentioned earlier, to even run the Apps Script that's attached to a doc. So they can't even, you know, use your application unless they have access to your doc. So if they have edit access to the doc or sheet or slide or whatever, then they also have access to be able to edit the Apps Script that's attached to it. So how does this work? We have a bunch of people that are all sharing the same, you know, doc or sheet or slide using the Apps Script attached to it. So, you know, in this given situation, right, you have like one app, say this is like an access to like these employees like Google Drive, you know, big query stuff like that, it's automating some process for them. They all have to be granted editor access on the doc in order to be able to use the Apps Script. And, you know, they're all sort of sharing it together. So they've all authorized this, you know, thing to access their services on every half. And then, you know, you have one user that's malicious, and of course they have editor access on the doc. They go in, use their editor access to modify the Apps Script attached to the doc to contain instead of the legitimate script, a malicious payload that does something nefarious. Right, maybe like, maybe like X will trace the docs that they have access to that the attacker doesn't have access to something like that. And then when the regular users come along and they trigger the Apps Script like they regularly do, right, the malicious code now runs as them. So this becomes, you know, it's basically very, very hard to write an app like this securely because, you know, just in the way that the system is designed, you have to get people out of the access. And when you do that, then you have access to edit the Apps Script. And so any shared, you know, documents with scripts attached to them become very exploitable. So we can do actually even do one better than this. So, you know, this piece of tech kind of implies that you have to wait around for these people to trigger this Apps Script that's attached to the doc. And as attackers, we're often quite impatient. We'd rather force this to happen like right now. So this can be done essentially by you can force a retrigger by basically going to the Apps Script and you can publish a web endpoints. And when you publish this, you essentially get a URL and that URL if it's visited by any of these users that have authorized this app, it will immediately trigger the script to execute as them. And this is this is actually really nice because it doesn't it's not just like they have to visit it like in their web browser. It's a web page that simply has an image in it that links to this URL, and it will completely that works completely fine it will execute the you know script is them just from like an image that links to this. So the way you do this is you just go to like to deploy menu in your Apps Script, you do a new deployment, you do a deployment type of web app. And you simply say like hey, when people hit the same point, I want to run as the user who's accessing the web app and you know, deploy it. When you do that you get this nice little URL back and this is what you can basically do to like, you know, you can put this inside of image tag or something or somehow get the victim to visit this in their browser. And this will trigger this script to automatically run as them. So another useful technique for you know lateral movement inside of a G Suite organization is enumerating and joining open Google groups. So to talk about Google groups right you know Google groups are used for ACL and both you know Google cloud, you know in GCP I am settings and for a variety of like G Suite style services rights. So they use extensively in ACL, but in addition to that they're by default when you create a Google group instead of a G Suite org, they're openly joinable by everybody internally. So by themselves, neither is an issue but when you put them together, this is actually not so great right. You know something that's used extensively for ACLs being by default, you know, widely open and insecure so anybody inside the company can join and basically grant the permissions of this ACL just by joining your group. This ends up being kind of a basically a factory for endless privilege escalation, right. So oftentimes searching and joining Google groups is a great way to just like, you know, escalate your privileges inside of a Google, you know, G Suite organization. So what all can be gated by Google groups. So imagine like Google cloud and all the services under it right App Engine, you know, Google Cloud functions, but it's also stuff like, you know, Google Drive, Docs, Sheets, whatever. Things like Google Calendar, you know, Data Studio and even like G Suite admin ACL groups and it can even be used for stuff like, you know, publishing Chrome extensions. So, you know, most Google services have some sort of ACL integration with Google groups. So tons of places to escalate your privileges. So talking about this in the context of like if you have an Apps Script implants, you know, unfortunately modifying Google groups via Apps Script is not as easy as it sounds. For some reason, unlike all the other like, you know, sort of Google services, the Google groups API is which is known as like the director API. It's restricted only to admins. So only G Suite admins can actually like utilize the API. But there is another API, which was called the cloud identity API, and that is available to all users. So your Apps Script implant could make use of it. And this allows, you know, some access to Google groups via the API. So some of the stuff that you can do with this is you can like list all the Google groups they give an organization, you can list, you know, the members of the groups, their roles, and you can also, you know, you can create your own Google groups. You can update them, delete members, you know, stuff like that. And you can manage stuff that you create. But unfortunately, the one thing you cannot do via this API is you can't join an open Google group, which is, you know, super unfortunate. But, you know, if you if you did have like that, if you did have like the full level access to the G Suite account, joining open Google groups is a great way to sort of escalate your privileges. So now we talked about escalation, let's talk about, you know, sort of like stealth and persistence right when you get access to a victim you don't you don't want point in time you want like persistent access you can keep fooling around inside the organization. We'll start off by talking about some Gmail trickery. One of the things that I recommend with your Apps Script implant using your API access to Gmail is create filters in Gmail to essentially hide security notifications. So things like the emails that say hey you just granted access to a new, you know, Google app. Those kind of notifications you can hide them from the user. You can also create a bunch of filters to like hide password reset emails. So you can like, you know, basically when somebody gets inbound password reset email, you can like hide it in either their trash or like some other folder, so that they don't see it. And since people's email accounts tend to be like the center of like all their security. You can then basically, you know, if like later on, you know, you can essentially do resets for all these sub accounts, use the Apps Script to pull the password reset email and let's get access to them. Unfortunately, you know, when it comes to like creating and forwarding addresses and stuff like this in Gmail, you can't do this via the API. But we will talk about, you know, if you have like the full access to their account, if you have like the full UI access to Gmail, you can do something that's called adding a forwarding address. And this is super useful for persisting access, essentially the way that it works is you can set it so that you have like an external mailbox like something at yahoo.com or whatever the external email is. You can make it so that, you know, anything that measures a given filter, or even just every email they receive a copy of that email will automatically be sent to this other email box right. So this way you can basically get a copy of all their stuff that's coming into them, and you can set this to like either, you know, delete the email or just like just make a copy and not make any changes. So this is a super good way to like sort of keep persistent access to their stuff, even if you end up getting revoked from, you know, or ripped out later on. So one of the things we talked about with this, you know, historical campaign where they used, you know, an app name of Google Drive, having a deceptive app name is quite useful. So you can tell that you can see here in this little demo if I try to set my app script app name to Google Docs. Yeah, when you actually go to the permission prompt there it shows, you know, won't it won't actually do it for you right it says like it'll basically deny it says you know it's still on type of project it won't set it to Google Doc because that's a misleading name and those you're trying to like do something fishy there so essentially prevents you from setting an app name like that. But, you know, and if you look into like some some of the some of the stuff that they've implemented after this, you know, Google Doc worm came out. All of the sort of like when they were doing the tricks with the Unico characters to like, essentially get the same looking name to like an official Google product. All of that has been pretty well stripped out like they have a good system for like preventing you from setting like G Swedish Oh GL Docs right all that's prevented. None of the know what space tricks in your networks. But I did find that you can use what's the magic of what's called the right to left override character. So for those of you that aren't familiar with this is it's a Unico character that you can paste in. And when you paste it, all of the proceed all the characters that come after it end up getting put in reverse. And so in this case you can see I basically paste the character in, and I go on to type in Google Docs backwards. And because this is reversed from, you know, right to left instead of left to right, it actually appears in the prompt as Google Docs. Right, so we completely bypass this protection by using this. And when the user actually gets to approve this they will just see Google Docs just as they did it with the, you know, initial sort of Google Docs worm. So our thing we want to do right is likely perpetual, you know, afscript execution so we want, you know, our script to continually have access to their account we don't just want like the authorize it runs once that's it we want to, you know, keep access keep persistence and keep around speaking figure out what's inside the org and do our thing. So afscript has a really useful feature which is, you know, time based triggers is sort of the crown style stuff that I mentioned earlier. And this allows for you know background execution on a schedule. And this can be run as often as like every minute. And it executes of course as whatever user was running the script that ended up programmatically creating this trigger right. So you can see some example code here, we've got script up, you know, dot new trigger it creates one that runs every minute and this will run our you know some function call every minute or so. Now if you read the Google, you know, the documentation on this it says, you know, in order to do this in order to run these background scripts, you need to request this specific scope which is script dot script app. And this will cause this like, you know, human this little thing to come up in your auth prompt that says hey allow this application to run when you're not present so explicitly warns the user that this is you know not this is running in the background it will run continuously even after you've approved it once. So, it turns out that this is more of a suggestion than there's a hard rule on this say you need to do this but as it you know turns out, it's more of a suggestion really. You can still create time triggers programmatically without declaring the scope. And, you know, as long as you declare some other scope of any type like Google Drive, Gmail, whatever it is, as long as they authorize those you can programmatically create time triggers while you want no execute just fine. So, you can use those persistent persist indefinitely and without any of this sort of a lot warrants to the user. So, or of a guideline that a strict rule. So great you know we've covered a variety of topics here around you know how you can sort of do everything from like pierce the perimeter escalate privileges pivot around persist and stuff like that. So thank you all for taking the time to see my talk, and be happy to answer any questions that you have.