Impersonating Google App Script Projects For Stealthy Persistence - Bleon Proko & Jakub Pavlík

Thank you all. Uh my name is John John Proco. I work as a cloud security researcher at Exa Force. This is a presentation that me and Yako public uh did on uh how to utilize um uh a feature that uh GCP GCP has which is or technically not just GCP. It's more of a Google wide because it also touches a little bit more on the on the Google workspace though the research itself will only touch on the GCP part uh and abusing it to maintain persistence that looks normal but it's actually malicious. Uh this goes along with my uh continuation of the researches. Sorry I forgot that slide. I promise I will edit when I just upload the slide. uh my I uh

I continue so throughout this about 3 years I've been continuing different researches on how to utilize uh different uh features in uh mostly cloud environments but also on-prem environments and then abusing them for uh for retrus so basically just use a feature as well as it is a feature but maliciously now uh what are Googlescript projects has anybody here has to work with upscript projects. One, two, three, four. There's four more people than I have met so far that use up script. I I was the first person in many people that I've asked to actually know that they existed. They are basically just uh a programmatic way of you interacting with different other services mostly as I say Google

workspace related stuff like uh uh drives or uh connecting to to different documents and writing a code that will programmatically uh execute a specific task on a specific uh situation. Now each time so this is how they look when when you try to to create them. If you go to script.google.com, you can create your own. Any user that has even a Gmail account can create one of them. You can go there, you can create one. Uh and uh that's how it's going to show. You can deploy them as there are different ways on how you can deploy them. I think yeah, there it is. You can have them as uh web apps, as APIs, as add-ons, as libraries. All of

them work in uh in a type of Java. JavaScript is basically JavaScript but they just have an extension of GS rather than JS but it's basically just a JavaScript code that you can use uh and as I said run a specific uh specific code. Now one thing that you will notice is each time that's uh created that uh project uh is uh sorry an appcript project is created a project a GCP project is actually created on your own arch on your own organization. It's just that it's being stored on a specific folder which is called uh apps uh app script. Yeah, appscript uh inside another folder which is called system.gcu which is there you there you have it. So

it's on that folder by default each time you create it. This folder is not list I mean it is listable but it's not listable on the on the uh web uh uh web browser. If you try to to click on it you won't be able to see technically. I now the second part uh I I should preface another thing. I have submitted this as a bug. This has been acknowledged as a bug. I have gotten a response that this will be fixed. I haven't gotten a confirmation that this is fixed. But on other tests that I did this couple days when I was doing the the slides and you know just uh doing the last test, I've seen a couple of

things differently from how I did before. So as I will speak in the in the end, some things will not work the same way as they did when I first started. So I will be showing how I believe this can have evolved in uh in this uh months since I have uh submitted the the presentation. But before even if you try to to filter them I wasn't able to to look at them. Now I can try to to list and they will be listed but sorry they will be filtered. But uh if you try to to click on that you won't be able to to see them which makes uh makes it a project that is part of your of your

organization which you don't know unless you actually go and execute the API through uh either the API itself or a tool like uh GPA. Now uh one thing that is uh that I noticed when I was uh doing this research is that uh this directory is technically writable to anybody that can write uh uh that can create a project you can literally just go and create a project there. So as an attacker uh if you would want to have a specific project ready for you where you can put resources which are not monitored especially on infrastructures where the uh detection is project based uh mainly the the infrastructures where you have a specific system connected and the

detection is made project based. You you would want to have a project somewhere that will not be looked by somebody else will not trigger any you know it will not seem suspicious but it will not be able to be you know it will actually work the same way as a project. So technically here if you can see the uh and uh the if you can see the whole zeros uh project is created directly on the organization and you can see here but the other one that is created directly on the folder which is the appscript folder is not listed which means that right now I have created that and I can continue to to create my own

uh resources there. Now what I why why would I want to have a project of my own? I can use another project somebody else has. One uh one reason is uh having specific resources that I don't want to be listed by other people unless I actually want them to or unless you know they actually go for them. One of them is uh setting up something like a crypto mining instance. I can uh create a project. I can set up I can link my uh new project to the uh to the building account and then I can create my my instance there and it will go at least for a while uh undetected. This is actually this research came uh after

some uh detections that we were making and somebody was trying to to abuse them and this is technically the technique that they tried to do and this is how we we found them out. Another thing that I would want to do is this one here. Uh if I want to have uh uh persistence in an organization, I can create I can use different things. I can have specific user. I can uh update the authentication of specific user. I can allow myself to impersonate a specific service account. I can create a service account or I can just have a specific project where I can have a specific service account where I can give privileges to how whatever I

want. I can even give organizational privileges to that identity and then I can go and access that and this is the the case when I go and create as you can see here this service account there is basically the project name at project name and that's how the the service account format works in in uh GCP if you if you have worked with it so it will be an email format of the of the name at project at uh the uh img service.com So this is the one created by me. Another thing that I noticed while I was doing the the uh the test was that whenever a specific service account is created sorry whenever a specific

appcript project is created there is a service account by default uh added to the um uh to the project. It's controlled by AWS or technically controlled by AWS. To be to be fair, it will have by default owner rights on the project because it needs to create all the resources on that project which will go and execute all the all the code that will be will be added on the appcript folder on the appcript project and it can be updated by somebody that has access to just go and update service account. Uh you can give it a specific role. You can if allowed by the uh organizational policy you can create a key for that you can allow it to be

impersonated basically the same way as a service account can be can be abused. Instead of going this route where you will have one more event that can be triggered which is the event of uh you creating a service account and then giving them privileges. You can just go this route and then just go and attempt to to give them enough privileges to not trigger detections while also having a persistence on the on the environment. And uh each and you don't even have to create a key for that because due to impersonation which is basically for those people that have used AWS is basically the equivalent of assume ro in is the equivalent of uh assume ro

basically you request a set of temporary credentials in the case of Google it's a token in the case of AWS is just three credentials. So yeah, this is the the first part. Uh if we don't have access to impersonate because impersonation is something that is triggered and is something that not every so it's something that is heavily detected. Adding that privilege to to a specific self adding an impersonation privilege from an identity to another is actually very very controlled. And uh in cases where we flat out won't have the permission to do that. We can always choose to do what we uh what we did before we can uh create a uh resource on that specific uh on that specific

project. In this case I created uh a function a cloud function and I can assign that uh uh service account to that function. I can trigger it uh unauthenticated or authenticate it if I want to continue using the user that I have. and then I can always try to to to run it. Now, uh the reason why I said authenticated or unauthenticated is because theoretically you can set an organizational policy that will prevent access for all users for specific tasks or all tasks. So you can uh limit anybody from having access from anywhere. So in cases where you have this error or where you know that this specific policy is being added, you can continue to use a specific user just to

execute that that function and after that you will go and have a set of of uh credentials which are admin which have administrative access. Now why even go and do why even go and try to impersonate if I can put it this way an upc screen. So basically just going creating a folder or just doing that when you can create your own folder. So if we go back on how we looked before and this is uh sort of test that I also did with my uh you know with my colleagues. Uh most people will go there. Most people will not go here and even and even if people go here, most people will usually look at stuff like

this, search them and be like, "Hey, this is uh this is normal." And uh searching on the on the internet, I can say that I'm probably the first person that actually went towards actually looking into those uh those projects as a malicious uh element. So uh somebody looking those at those projects from a specific user would just search and be like oh yeah this specific user has created that doesn't seem much because it's actually it actually looks like a legitimate thing that somebody else would do. They are allowed to do that. They are allowed to create them. Even if they just want to test it they are allowed to to to have that that feature.

The service account itself is something that is uh in uh it's something that is is created by uh by uh Google itself. You can see that also in the email part which is not the project.g G service account but the project is topspot which is uh technically a project which is managed by Google itself. We don't have access to that. So it would seem like this is just a feature being added and not being misused. And uh since technically there will be other resources being created there because the the scripts will need to be executed. It will actually it will actually look completely normal. I'm sorry.

>> Yeah. Okay then now that we saw that this can be abused let's see uh some way somehow we can uh we can see this being detected. The first thing that we will be looking at is the fact that uh billing account has been assigned to the to the project. Uh a billing account is basically a fancy name for a way to pay a payment method that's or not not even a fancy way. This is just another name for just a payment method. Basically, you have one when you create your own project and you can, if I'm not wrong, you can create others and then you can just assign them to two projects and each

time a project uh resource is created, it will be a pay as you go, a continuation of money being retrieved from that payment uh method. Uh by default, Appscript projects do not have them because they are not as resources uh or the resources behind that are not managed by you. they are managed technically by by Google. So the first thing that you will notice is this one. But there and uh yeah one way the attacker can be crafted about that is just going and unlinking uh the uh the billing account from or just not adding them at all at all to the billing account. Uh the thing is for resources that do require that uh that will quite

literally just destroy the resources. As you can see here, the the crypto mining instance literally got terminated just by us unlinking that. There are some resources though that do not require that at all. They do not require uh a billing account at all because they are provided and I think it's on this no uh they are uh provided to to us by the free uh free tire and they are provided as uh free resources without any cost. IM is one of them. So if we want to continue on the route of hey we want to add identities here which are going to be used as persistent we can use that not have the project uh linked

to the billing account and still make the project seem completely normal. Another uh indicator is that each time an a the API is used in in I'm using the word Google. I think this is just for GCP and I think Google workspace has other APIs but at least for GCP each time you are going to use a specific resource you or a specific API even Google cloud it will ask you if you want to enable this specific API before all of them will be listed on the services enabled. Now uh by default an appcript project will not have any services enabled but a malicious one will have because basically you are using those as uh as a way to create

those other resources. Now again an what an attacker can do is just disable them. One thing though again some resources do require some services while in use. One example that I noticed was the uh compute one. uh when you have an instance being created by default the service of uh compute and o login by default needs to be enabled or otherwise the resource needs to be deleted. So if they have created some resource like an instance and they have this service or in the case of cloud functions I think the uh API for that needs to be enabled. So if they have created some other resource other than you know that some other resource and they need to use the

API for that those services cannot be disabled while those resources are in place. So as a detection as a the detection way this is another another thing to to look at again we go back to AM which is the persistence part as I said am does not so uh I I only saw these four services but I'm pretty sure there are others somebody that has time can go and and look for them but I uh IM is one of the services that do not require the am service to be enabled. so that you can interact with it because by default and it completely makes sense if you are going to use a specific API and you need

the service enabled first then you need permissions and the service enabled so that you can enable the service which completely doesn't make sense so it it is completely normal that IM at least will not require you uh the service to be enabled uh so again we can continue back on the persistence part we can uh create an appcript folder completely legally just by having an identity compromise. We can go uh create either create the service uh account or just abuse the service account that we that they provide by default. We can have administrative access on the on the organization and then continue to do the things with uh with other identities. If we get kicked out, we still have a way

back in a privileged one. That is uh the last part is the way that the appscript projects are created. If you create an appcript project directly from the uh from the scripts.google.com the identity that will create will be this one here. But if you create them manually the identity will basically be the identity that's created. So so this is the difference between legitimacy and illegitimately creating projects. Again, this can be bypassed. The way you bypass it is quite literally by just going and creating the project as uh just by using the script.google.com. You have the identity, you get access to the browser, you go and create the project, you uh uh complete, you know, you add or abuse or just update the the

service account or create another service account and you again have everything ready. So in this case we do have an environment that seems semillegitimate unless you are actually going and looking for specific things which are going to be there. And still uh we also face the other part which is how many people would look into a resource that does seem to be uh provider specific and actually going and going down the rabbit hole of analyzing that rather than going through the other steps to analyze what the attacker actually did with other things. Now uh there is this uh so while I was testing I was like okay let how do I solve this? I don't we don't use them. I

don't have to use them. As I said, I I met four more people than I've ever met that use up script projects. What happens if I don't want to use them at all? You can just literally create uh uh organizational policy that says uh prevent any create or update of those projects. So any new projects will not be created, but if there are old ones, you can just uh you know prevent the update update of them. and that will block the uh malicious creation of the project and also block the the uh legitimate creation of those projects. Now we uh submitted this to to uh Google. They uh admitted this is a bug. They said that they are going to fix it.

Again, I haven't gotten uh confirmation that this has been fixed. Uh and but you know, I got into the honorable mentions on their bug bounty, which is I I think that's a win. But uh as I said before, I again I'm not certain that they have fixed something. But while I was doing the test, redoing the tests for this uh for this talk, I noticed that on our production environment, each appcript folder would be listed not in the uh appcript directory anymore, but directly on the organization while the uh on the lab environment that we had, they are being created on the app script which wasn't like this before. before everything worked like this. Everything was moving

like this at least some months ago. So I'm not certain if this is a partial attempt of them to to fix stuff and then later on everything will be looked like that which is basically all the projects will be listed as projects not stored on specific folders or at least they will be stored on specific folders but be allowed to be listed normally as in any other folder. I'm not certain of that. I haven't gotten a confirmation. So take all of this with a grain of salt. I just wanted to to add this as a as a continuation of your own detection or attack in case you are going to use this technique. Sorry. Now other things

other extensions to to this uh research. I haven't had the time to go through this really go through this research. uh we had a lot of ideas on how to extend this on how to abuse other features that it had. But if we go back to the second slide uh we see that uh the uh appscript folders are used for many things. They are as as I said there they are very flexible. Uh you can use them to to interact with different services. You can use them to to build uh web apps and stuff. No, out of them these three are in my opinion in case anybody would want to continue this research. These three in

my opinion are u next researches that can be used on that. uh one idea that I had which was theoretically an idea but I never got the chance to to to to go through it is uh in uh Google and GCP and in in again I'm using the term Google because I'm using I'm using Google as GCP plus Google workspace. So when I'm use I'm saying that it's both of them. uh there is something called a domain wide delegation which is basically you allow a specific identity to have access to basically any other identity around. One of them is uh the uh the ability to go and impersonate basically any user that you would want and then access the

resources. One idea that I had was create an appcript folder folder and since that folder will will allow you to go and access uh resources which are controlled by you uh drives files and whatever calendars, emails and stuff. You can go you can create that folder you can create an identity with DWD domain wide delegation. you can give that permission to go and uh access all the files or any identities and now you will have a persistence mechanism on the entire Google workspace for the entire organization for the entire users and control basically every file that they have. You can temper with the files. You can read the files. You can temper with their calendars and just try to fish

them. You can uh you can enumerate. You can uh steal their data. you can try to find uh important data that might be stored there. Again, I haven't had the time to do that. If if anybody has the time to to get into this research, I think it's going to be a valuable one. But yeah, now as conclusions, uh this is again not too deep of a research per se, but it's something new that unless you knew about it. Uh you would not look into it so so in depth. uh it's uh it's a feature that you can abuse to to maintain as I said persistence into an organization or just create resources uh while still looking

as a completely legitimate uh environment and in an environment where you are using this uh it's going to be a lot harder because now it's a matter of okay who of the users actually has rights to do that and how am I checking if they are just testing this specific feature or or not. Uh again, it's something to to to keep in mind in case an attacker will go and abuse this and try to to get and with that. Thank you very much for

>> Yeah, I'm I'm bit confused about the disclosure. So, you reported it to Google. >> Yes. >> They acknowledge this to be an issue. They will fix it and they didn't ask you not to disclose it to the public. >> No, no. I actually uh I actually even told them I will be writing an article about this. So whether you want to fix it or not, I will be writing something about it. That's normal. >> Yeah, it's it's up to you to fix it or not. And I told them I can wait. I don't mind. And this is usually how I do my disclosures. I because I know very well if I leave a disclosure it will always

get stuck there. So I always tell them I will do this. So it's your choice to fix it in time and we can discuss about an extension or just leave it there and will help anybody. >> Okay. >> Uh yeah. >> Interesting. >> Uh any other questions? One, two, three. Ding, ding, ding. Thank you very much.