BSidesSF 2026 - Red Teaming from outside: Identifying and exploiting SaaS systems... (Rojan Rijal)

Thanks for joining us everybody and sticking out sticking it out to the last session of the conference or at least in theater 9. All right, give yourselves a round of applause. Yeah. And and also round of applause for erosion here from Orphan Security Incorporated. Uh he's going to be talking today about red teaming from outside identifying exploiting SAS systems. Um if you didn't catch the QR code um for the Slido Q&A, go ahead and go to bsides.org/qna. orgqna it's Quebec November alpha not amperand so and then that'll take you to slido to submit questions for uh her roion to answer so yeah take it away thank you >> okay what about now >> perfect all right thank you everyone for

coming to the talk today again as explained red teaming from the outside identifying and exploiting SAS systems a quick introduction to myself uh my name is Roan I'm co-founder at security. We do security research like what you'll see today. Uh we also do offensive attack surface management for red teams and then pentest. After the talk, if you have any questions about the talk, any of the research stuff that we talked about today, feel free to reach out on Twitter via Malexis or Ofian Security or you can ask me questions outside as well or via LinkedIn. Any of the medium is okay. So for the focus of the talk here today, we're going to focus more on

email security vendors exploiting and abusing some of the systems they existingly have as well as exploiting Google groups with the end goal of getting access to internal systems uh for organizations. We'll have some real life examples and also do hopefully a live demo. Uh if it doesn't work, I have a recorded video just in case as well. Now in terms of email security vendors, what we wanted to focus on when we started investigating and looking into it is in general all email security vendors are designed is to prevent fishing attack. But we wanted to reverse that. We actually wanted to use email security vendors to do fishing attacks and exploit internal systems through those. So that's where we started uh

some of our reviews and looked into two different ways some of these vendors would work. The first one is for external reporting systems that organizations have. What I mean by this is let's say if you get a fishing email that is acting as Apple or Facebook, they actually have an email address where you can report those and they will investigate if it's a large uh scale fishing attack. They will take down those domains, work with authorities and whatnot. Similar goes to Square and Facebook. There's other hundreds of organizations that have features similar to this. We wanted instead to utilize these and abuse that. Same thing goes for internal side of it which is more for email security gateways that

organizations use to prevent fishing attacks from landing in their employees inbox. So examples of that if you have encountered them would be things like mcast, proof point, barracuda, sofos and various more. The idea was can we actually use it and see what happens. Now while there is external where you can report to Facebook or internal for employees most of these work in a similar uh design. So from the internal side, employee is the one reporting a fishing email or they might have the vendor scanning every single email that's coming through the inbox. For external, they're relying on customers to report these emails. When it actually comes to it, at the end of it, the analysis is that or the process happens

the same thing regardless of what the initial reporting was. The intake process will check if there's a grammatical error, if there's a spelling error, domain history or URL analysis as well. Now domain history is checking is the domain new URL analysis is where we focused on heavily. It's checking is that URL safe when you open it is it going to show you a fizzing page and they will actually send unauthenticated get request. That's crucial to have unauthenticated get because you don't want to send any sessen values there. You're just hitting the URL with various different user agent. you are mimicking things like mobile uh like iOS device, Android, Windows and whatnot just to see which one is a fishing page, which one

may not be a fishing page and report that back to the user. In the result generation, that's where they will do a report for sock teams to analyze. Now, after all of this, we wanted to actually focus on the URL analysis portion and reverse that and actually use it for our attacks. So the first attack vector we utilized was to actually send emails by using email security gateways to bypass them and also send valid fishing emails to organizations. Now in most cases what we identified during this is some vendors when it comes to email security gateways like again mentioned like mcast and others the process is similar. Some would check only the inbox that exist. So if a email

inbox of a user exists, every email there is unfold or they'll add a rewrite URLs to it to check if it's a valid fishing email. Second, some of them will actually check any email that's coming to the system mainly because the organization would have their MX record pointed as a middleman to the security gateway and then they'll handle it sending it to things like Gmail or Office 365. Those were really valuable because you can just create inbox that don't exist and send emails to it. It will still scan that and then proceed to actually deliver if the email inbox exists. So in our first attack vector, we started to investigate ways to abuse it. The first one we looked at was with

Amazon SCS. A big uh transparency warning whatnot here is it's not Amazon SCS fault of this entire attack vector. We just used it because it's the easiest way to send transactional emails or marketing emails and easier on our end to test as well. The reason behind that is for Amazon SCS there's two different ways you can confirm your identity to send emails. One is by verifying your domain which will require DNS records txt and everything. Obviously on our end for an organization we cannot do that especially if we're targeting an organization. But email address wise the verification is simply through a URL. What that means is if you provide an email address for identity verification,

it will then send that email a link to click to verify it owns it. If it's clicked, then it's automatically verified. So as an example here, if we just do it for email research at secl. Once we create that identity, it will send us a link. We click on that link and now we have a verified identity. We can then send an email from that. So at first we're like, cool, this works. We can probably send emails to organizations in mass and see which one of them click a link. If the vendor opens that link, it should be considered clicked aka verified. So we should be able to then send fishing attacks. That didn't really work because we have

the classic case of having SPF, DKIM, demark, everything being checked. So even though we had a verified identity, we couldn't really send an email. But at the same time AWS has a really great feature or before that if we just look into this was for a real uh organization we targeted the from address is redacted for their security providing their email getting it verified we still couldn't send the email but then we realized in SCES there's a mail from settings that you can configure which is basically saying even though I'm using SCES where it will set the mail from header to be from amazon.com domain and it will most likely fail the SP VF and DKIM. If the

org doesn't use Amazon SCS, we can provide a custom mail from domain. So, say for example, if I'm targeting off security, I could do a subdomain like email.curity.com. As long as we have a MX record and txt record, point it to those value that mail from is valid. So, we started looking for various organizations we tested. Can we do subdomain enum to find out if they're already using SCS? find if they already have MX and TXT record within that subdomain because let's say if we're targeting example.com as long as the subdomain email.example.com has that value set we still can use that as a mail from value. Other example in this case when we're targeting this specific

organization we simply went and signed up on their website and started getting marketing emails and realized they were using Amazon SCS. They actually had a subdomain Amazon sees.acample.com example.com which they were already verified for the mail from header. So we went ahead and provided that to Amazon's SCS configuration. After that we're able to then basically have this whole flow working. So we have now a way to create an email identity. We could create an email security vendor and finally we can send fishing emails and it would actually land on users inbox without any sort of u SPF checks or without any flags from Google or any of those and it will actually flag it uh through that

organization too. Now that was more sending the fishing email but as the talk title said we wanted to get access to internal things. So we looked at the same email security vendors at first to see can we get into internal groups of their or internal SAS services of different organizations. So our first chain was to look through domain capture uh which is basically a feature that exists in almost every SAS applications at this point. So say for example if you go to Slack you provide your company's email address it will give you a list of workspaces you can join once you have verified that email primarily done through the domain that's on that email address. In this case, if

we're able to get any kind of SAS applications to do a email verification through a get request where it just sends us a link and as long as we click on it, our account is verified, we would be then potentially be able to access any of these potential uh SAS applications or resources that are vulnerable. So in order to identify SAS service, we started looking at various different ways where you could go and brute force and whatnot. The most reliable way in terms of moving through this attack vector is just look through the TXT record for that root domain of a company. So in this example, if we look at Netflix, you'll see they have a lot

of TXT records for services they use where they have verified the Netflix.com domain. So examples would be things like Atlassian, Anthropic, Dropbox, uh myro Miro and all of those. knowing that the target then would be to find the SAS service they are using, see if they click on an email and exploit it. One of the example that no longer works uh but worked in the past was with Atlassian cloud. In Atlassian's case, you could create an account, provide an email and a password. It will then send a user verification link. As long as the email clicked on it or if the user clicks on it without having to relog in or have an active session or without performing any

activity on the page, it will automatically verify it. It has now been fixed reported by um edge cash money. You can follow him on Twitter as well. Great hacker. Now there are other SAS services that is still possible. And so Atlassian might have fixed it, but there are other orgs. We didn't mention those SAS service here just for certain security reasons, but it's super easy to identify. You can just go and create accounts in different SAS applications, see how they handle email verification. If it's fully unauthenticated and just a get request based, then it most likely is exploitable as a chain when you have a email security um gateway being used. So in our case for a real world example, we

targeted Netflix in this case. Uh a big warning here or big uh transparency here is like we work with Netflix teams when we do these kind of research. We report these vulnerabilities because they accept things like enterprise related vulnerabilities. So they are a great team to work with uh and they give permission to disclose this vulnerability. So hence why we have it here today. In this case for Netflix, similar to what I first mentioned about about users being able to report fishing email, Netflix has an email address called fishing@netflix.com. If you ever get a fishing email that's relating to Netflix, you can send that there and it's auto analyzed. In our case, we instead abused that and

went to atlassian, signed up with fishing@netflix.com, provided a password that we controlled, waited for atlassian to send that email verification link. In this case, the third party vendor that was receiving all the fishing report emails had automations which will unfurl the URL and analyze it which then autoverified our fishing@netflix.com account. And because Atlastian Cloud has domain capture where it will give you options to join Jira or Confluence or any other workspace with the Netflix.com domain, we're able to then join internal domains or internal Jira instances of Netflix in this case as well as list any other available Jura and Confluence workspaces. Now that's on the email security. So that was like a real quick example of

how you can abuse email security vendors. There's a couple of more attack vectors you can do with it. uh but with in terms of getting access to internal systems as long as a third party doesn't or does unauthenticated get request you will be able to get access as long as the target is using a email security vendor but then we moved along and we wanted to target something that's more common and more easier to use so we started looking at Google groups when it comes to Google groups it's important to differentiate our focus was primarily on enterprise Google groups not necessarily the public Google groups that users can just create enterprise Google groups are different and I'm pretty sure most of us

have interacted with it. Uh especially if you're a Google Workspace customer they will have all the similar security settings except the two with the anyone in the organization can can ask and anyone in the organization can join. The other three ones that are existing and available is anyone in the web can join, anyone in the web can ask and invited users only. pretty easy to understand in terms of the permission layer of like if you have anyone in the web most likely anyone in the world can join. So when we started looking at it one of the things we realized in terms of the permission settings when it comes to Google groups is that a individual group

setting is also kind of influenced by at the organization level group settings. uh it cannot go above that security boundary as expected but having some organization level settings that is misconfigured can then affect all of the Google groups allowing users to me mess it up as well but at the same time on the other hand we saw organizations completely restrict their Google groups where nobody in the org could actually create it. It has to be an IT person creating it or some kind of automation flow creating that kind of Google group. Now as an example if we look at this organization layer settings in the org level we are setting that the group owners will allow external members. What

this will do is it now lives to the group owner of how they configure their groups. As an example it gives them four or five different permissions. One is only invited users. Anyone in the organization can ask, anyone in the organization can join and anyone can ask and anyone can join. Those two settings are really vital when it comes to actually exploiting it. um versus if you actually disable that at the org level in individual groups they only get access to three levels sub permissions which is anyone in the organization can ask anyone in the organization can join and only invited users. The reason I mention that is even though you might have that group settings a lot

of the misunderstanding we saw happen was with the private setting that Google group allows. This is common for all organizations to have that enabled to make it private. The goal behind making it private is that it does not let the Google group UI be visible to any external users. So if we were to go and look for a Google group for Netflix or Uber or any other organizations, it won't be possible because the private setting is enabled. The misunderstanding there is could that actually prevent an user from joining from the public? Not necessarily. So when we started investigating we wanted to identify all Google groups see if we could join them and then actually use it for bug

bounties or research or red team engagements but pretty quickly we realized again as expected if you have private we can't really access it so even if we take off security as example if you try to list the public all the groups it won't give you that permission and that's where a lot of uh organizations thought was well you can't see the group so how would you even join it so when we started looking at it. Turns out or before we actually do that, I'm sorry I'm all over the place with that. We wanted to find ways to confirm that a group existed for an org. So if we go back to of security, we can't tell which groups exist, but how

do we go and identify that? So we identified a Google group API that you can utilize where you can just pass in an email address. It will tell you if that email is valid and is in Google Workspace. It doesn't tell you if it's a Google group yet. It gives you a user ID which confirms that the email address exists. But then the question was how can we confirm it's a group? Because if we're about to spam emails to it, we don't want to send it to users. The best way turns out is you just ban the Google group you're trying to attack. What I mean by that is you can create a public Google group that is

freely available for any users and you can ban the email address you identify to be valid which in this case it will respond with the actual group name and also give you the hyperlink confirming it's a valid Google group. So at this point with the attack phase while we couldn't see a Google group for an organization we had identified ways to confirm if groups existed and if so what was the email address of that group but then the question again was as I mentioned before you can't see it so you can't join it but turns out groups has four different email commands that you can use one of which is actually plus subscribe. When you send a group an

email with just saying let's say group plus subsubscribe@acample.com it kicks in a validation process to see if you can join the group and if you can it will respond with a confirmation code allowing you to join. When we realized that our idea was simple let's find a list of all Google groups for an existing organization. Let's email it with a plus subscribe and see what responses we can get from an external side especially if you're not in the org. there's only uh few emails responses that you can get. And in this case, the best part was when you hit the plus subscribe, it is not sent to the admins or the users. So there is no spam

you are generating. It's more or so Google group handles that based on the organization's permission layer or the group's permission layer which we talked about previously with the anyone can join, anyone on the web can join, organizing can join and invited users. When you send those emails, you get one of the three responses. So the first one basically tells you you cannot join. Don't worry about it. Uh the third or second one tells you you can join but it has to be approved by the admin of the group. So that's where you have to still send a request. The group admin has to accept it and then only you can join that group. The third one however is

interesting where it just sends you a confirmation code and you respond to it and you will most likely be able to join. So in this case with the subscribe process if a group is vulnerable you get the confirmation code then you email back the group with a plus subconfirm command give it the confirmation code in the subject. If that works and the group is public you'll be able to join. So even though the setting is private you cannot see it you still add your email address to the mailing list which allows you to then see all the incoming emails because you will be CC to all of them. So you no longer need to have that UI

access. you can still see those groups. Again, as an example, we tested this on Netflix. We identified multiple Google groups, one of which ended up being publicly joinable. For our case, it was test3 at netflix.com. The caveat here from a sensitivity point of it, the group didn't get any sensitive email. So, it was just created for test left vulnerable. But in our case, if we think about it, now we are able to join a group, which basically means we have a inbox with a Netflix.com domain. So we did the same thing again. Let's use domain capture. Let's find the workspaces. The one the change here is we no longer are uh separated by the need of having just a get request. We

basically get all copies of the email. So we can get confirmation codes, we can get join requests, all of those as long as we are member of that mailing list. We could then do the same thing. So in this case we used the Netflix.com email for the group we had joined put provided it in atlassian. no longer needed to wait for a get request to be hit. We had the confirmation email, clicked on the link ourselves, then we're able to join Netflix's Atlassian one more time. There's 100 more workspaces you can join out of those as well. But the other benefit of that outside of the Netflix uh workspace is you can also create a

Google account to use with sign in with Google environments. So now you don't have to go to a SAS environment like Slack and others and keep providing your email address, provide a confirmation code and join back and whatnot. You can just switch sign in with Google. One thing I will add here is if you are worried like how can someone create this uh Netflix.com account in Google, it doesn't add us into their Google workspace. It only gives us the ability to do like basic things of like logging in with Google. Same thing uh on Google if you're like trying to create an account where you can say hey I don't want to use you as an inbox. I just want

to use like have a general Google account. That's the setup you can use for this. Uh one thing you can do from an organization side of it is you can work with Google to block your domains from being used on these kind of signups. So couple of organizations like I think if it has not changed yet. Shopify used to do the same thing where if you provided a Shopify email address to Google signup, it will actually prevent that and they will say you cannot try to create an account with Shopify domain. So if you're worried about your organization having that or having that risk, working with Google would probably the best option to just completely block a Google signup.

U in terms of preventing from the organization level, one thing we looked at is actually looking at how can orgs prevent it and do it at scale. So you can go through individual groups and check if it has can join the group for anyone on the web. Even though if it's a private setting in org, you can still join with the email command. But you can also use the API. However, there's a little bit of a quirk with the API where it doesn't give you the full output. So, as an example, when we created a vulnerable group uh intentionally vulnerable where it was joinable to the world, you'll see the permission says anyone on the web can join, but the API

response is all in domain can join, which lives the uh perception that it's only restricted to your org. So what we came up with the idea there is if you have a Google group that says allow external members set to true and has a all-in domain can join there's a high probability that your group is vulnerable. So I would recommend at those point to check and see if that group is actually vulnerable or not. And there are a couple of ways you can do it externally by sending the plus subscribe email or you can just check the group directly internally as well. Now we move to the second exploit with Google group still. So Google group is

where we focused a lot and there were a couple of things we're interested in as an example when I mentioned before group handles your permission and settings. So if you set anyone in the organization can join they're taking care of that in terms of how the user joins that group. In our side we're like how does that actually work? So we started investigating it um and started seeing that a lot of orgs do depend on anyone in the or can join. So we wanted to see does that really verify if it's so like is it looking at the Google workspace users? How does that actually work? So we created a couple of test examples. So

we created multiple Google work uh workspace organizational units within one Google workspace account and started checking what that permission layer looks like. So for example, if you have security test and sample email2.com in the same org, user in the security test can join groups in or a.com which is a primary OU unit or the user in contractor.org.com can also join uh groups in or.com. Even though it's a subdomain, they are still considered valid users, which was really interesting because we were like, okay, it still doesn't tell us how the users are being validated. Is it checking it? Is it checking like user list and whatnot? Then a good friend of mine, we previously saw like Atlassian fix from

his end as well. Tanner posted a blog about doing a fishing attack by using Google group. In his case to summarize what he had done was created a fishing email from a company's website. So he had signed up in the SAS platform, sent a fishing email out by basically doing HTML injections on on on the email coming out of that SAS platform to the internal engineering group which for his case he was like it worked but I don't know why it worked. So when he started investigating he found out that when you set up anyone in the organization can post it's basically saying that Google allows manage domains to post to internal groups from any email address

on the domain regardless if they are a defined user. What that means is if the email incoming to the group when you're posting to it is a valid email. So SPF DKIMD mark everything is passed the domain is part of that Google Workspace account. It can then post to any internal org as long as it says anyone in the org can post. When I saw that we're like okay that's interesting. So if you can do anyone can post can't you do the same thing with anyone in the org can join. So then we started creating some theories of can we join groups that are in organizations where we can control the emails but if we do how do we receive these inbound

emails? So our first attack theory was we need to find companies where we can control the outbound email with a domain that they own as well as the organization will provide us an inbound email where we can receive emails. Then if we can control the from header of the email address because for Google group it does not respect the reply to header. So say if the org is emailing from no reply@acample.com but the inbound header is reply plus idly.acample.com example.com, Google will automatically respond to the no reply email address as opposed to that inbound one. And also, if we can control the recipient of the email, then there's a high chance if we identify list of groups, send a bunch of

subscribed requests, there's a more chance that we can join internal groups even though they are set again for internal users only. So the first ones we started looking was to find services that do that as a inherent feature primarily HR platforms and support platforms. So if we look at HR platforms, if you work in recruiting side, you most likely have interacted with cases where if you're emailing candidates, the platforms handle that email. They will take the inbound email, they'll send it. If the candidate replies to it, they will intake that email and post it on the thread for that job that you created. It doesn't have to be your company's domain. It could be a

domain email that they use. Support platforms is a similar case. If you are on customer support or if you have interacted with support cases in the past, you'll see that a lot of support platforms either give you a custom subdomain with their root domain. So example helpportal.com or they might just use a classic just old school inbound email like reply.help.com and all users are using that specific for their SAS. So the idea here was for the HR platform if we are able to add a candidate create a job create schedules and we can control all the email flow we most likely can join their internal groups. So the idea for exploit phase if we just

look through the mapping of it is from our side we go and find a recruiting platform we create a job and add a candidate we can then schedule a email interview with the candidate. the candidate can reply back to us as organization and at that point all that email that the candidate has responded to shows up in our inbox. So in this case if we go back to the attack flow we thought we can control who we add. We can see that there's an outbound email from the target company's domain and then we also have an inbound email because if the candidate responds to that job we'll be able to see it in our thread.

So, we targeted a specific recruiting platform, uh, not naming it here for security reasons. We're able to create a job and add a candidate to it. When we do that, it sends an email to the candidate saying, "Hey, an interview has been scheduled for you with the application ID at inbound.red.com." What then happens if is a c if a candidate responds in this case with the redacted email to that same application ID at inbound.red.com with a response, it shows up in our thread. So at that point, we're able to control that inbound email. We're able to control the outbound. And if we go back, the actual from header includes that inbound email. So it's not using a

no reply, none of that. It's the direct email of our job ID. So what we then did was went ahead and identified bunch of Google groups within that organization, sent a plus subscribe request to it. Within that, we then got a response back for when we created a candidate with a plus subscribe email address and scheduled the interview for that candidate. Google group said yes this is a valid email because it passed all the SPF the organization SAS platform is sending that email it is part of a root domain that is in that Google workspace account. So it sent us a confirmation code to actually join the group. Once we responded back by changing the candidate email address to

the plus subconfirm header or uh command were then added to that group. What that does is the application ID that we had as an inbound. So app ID atred redacted.example.com example.com is automatically added to the mailing list for that internal group, allowing us to exfiltrate every single email that's coming to that internal group. So, this is a demo example there. Now, what we're going to risk doing is do a live demo on a targeted org and we'll see if the demo works. So, we have a environment called work IQ.AI and they do hiring process with AI. Fair warning, this is a test or we built a fake company completely from end to end. So it's not a real company we're

attacking. But in this case, this is pretty similar to what you'll see with any ATS platform. You go as your org, you sign up, you can create an account. So I'm going to create a test account in this case.

Now from the company side, I'm just going to fill my company information. I want to recruit people for security and role.

I'm going to create my first job for people to apply. put it in San Francisco.

Now once we have the test job created, it's a matter of just creating a candidate. So let's say I want to refer someone internally. In this case, from attacker side, I'm trying to see how the inbound flow actually works. So I'm just going to create a test account.

Once we have the candidate created, we're going to add an application on them. So, we have referred them internally and now we're going to reach out to them.

What I'm going to do is I'm going to unplug my HDMI real quick. I need to switch my email. So, I just realized I didn't have that ready. Oops.

See if that rolls. Perfect. U So, in this case, this is from the candidate side. So, we can see that the inbound email address is similar to what I showed before. Application ID@mail.workiq. workq.ai. We're targeting the company work IQ in this case. So, as a candidate, I'm just going to respond to the email to make sure the inbound flow actually works. If we wait for about 30 seconds, we'll be able to do that. While that's happening, still from work IQ side, we don't really know what groups we can attack. So, if we go back into our bursuit testing instance and we have work iq.ai, AI. We can send this into intruder to identify Google groups. We'll just use a

short list of directories. Uh you can use any other stuff. I just use directory sort for demo in this case. Once we send a bunch of requests, we can then look for values false. We'll identify three emails that actually exist. So we have accounting at which has an ID, internal at for that organization, and security at as well. But again, we still don't know if that's a valid Google group. So from our public uh account, we're going to go and ban this email address. So let's say if we go and ban internal at workiq.ai AI and list of band users. We can see that it created a name for the user which is coming from the Google group. We can

also see a hyperlink there. So that confirms to us that group exists in work IQ. Now if we go back to the application details. Well, it looks like the demo failed. Great. Give me a second to double check. All

right. This is why we have a video backup.

So, we're going to do a video instead of the live demo because the email workflow we created didn't work. So in this case, we're doing the same attack here. So you'll see from the attacker or the candidate account, we're responding to the email address. We wait for a few seconds to see if we get our email reply. Uh after a few minutes, we'll see that the candidates's response has actually came back and it's in the thread. So we have the inbound email. We're able to send an email. We know that we have identified couple internal Google groups for this org. So we're going to go and change the candidates's email address. So now we're on the

attack mode of actually joining the group. So we'll send or change the email address uh from John Rodriguez to internal plus subscribe which is sending an email command to that Google group saying hey we want to join with this random application ID at email.workiq.ai. So we're sending that email now. We're just doing a join request. It gets sent. We wait for a few minutes and we get this response back from Google group. So in this case again from a completely outside point we have sent a request to that internal group. It has sent us a reply back with a confirmation code for it saying hey you are able to join. You notice it doesn't say it needs

admin approval or invite only. Uh even though the group setting is set to anyone in the org can join. So it shouldn't let public folks to join. Now that we have the confirmation code we go back again and change the candidates email address.

Now it has been changed to internal plus subconfirm. We're confirming that we can join the group. We're pay uh sending back an email to that with the subject of a confirmation code.

We wait for a few seconds to Google to confirm that.

And now we have joined the inter group. What that will do is it will basically put that inbound email address as a mailing list user in that internal group. So all incoming emails get automatically added to that job profile in addition to all the employees being sent those emails too. So we'll be able to exfiltrate all emails out of that. Let's go back to our slide. In terms of preventing this, we reviewed a lot of platforms that are vulnerable. Um hence why we haven't mentioned some of the ones that are still vulnerable. Some have already patched it. Uh for preventing the biggest way we saw was if you just change the from header for the

initial emails or any emails that get sent and use a reply to functionality. It prevents joining those Google groups cuz again Google will not respect the reply to header. It will only check the from header. The second part of it is a little hard is to basically change your entire domain for outbound and inbound emails to make sure it's not in the same Google Workspace account. Uh so say for example in work IQ's case instead of using work iiiq.aii email address we'll register work iqmail.com most likely not even have it in Google workspace because it's not designed to be used with Google. Um so in those case as long as you're using like AWS and

whatnot to send and receive emails you'll be safe. It's not part of the Google Workspace account. So you'll be able to uh prevent attackers from joining the internal groups. That said that wraps up this presentation u in terms of groups and all of that. If you have any questions, more than happy to answer it. The light is kind of blinding me. So if you send answers on slide or questions on slide, I'm more than happy to answer there too. Thank you everyone. >> Thank you Rajin. We do have few questions and if you guys have any more questions please add them on slider. Uh first question is how vulnerable are other SAS providers like Microsoft 365

compared to Google groups vulnerabilities you talked about. >> So in this case for the group attack we did not investigate office 365. We looked at like teams and other relatively quickly. We didn't focus a lot on it. Um so I have like not direct answer on how vulnerable they might be in terms of when it comes to like the Google group related uh issues compared to office 365. Okay. Yeah, that's yeah >> that's it. Uh being said that here's a little something from besides for you. >> Thank you. >> Let's give him a round loud round of applause.