Amy Ciminnisi 0:00

Welcome to the Talos Takes Podcast, where we discuss Talos' latest research and security news. This podcast is for everyone, from the C -suite to the frontlines.

Amy Ciminnisi 0:12

Hello everyone, and welcome to Talos Takes. I'm Amy Ciminnisi. Last month, Talos published an article about the abuse of software as a service platforms like GitHub and Jira to conduct social engineering campaigns. These spam and phishing emails are delivered using the same legitimate, totally legitimate, mail delivery infrastructure as GitHub and Jira. This makes it less likely that they'll be blocked in transit to victims since they meet the standard authentication requirements like SPF, DKIM, and DMARC. And these campaigns are mostly associated with phishing and credential harvesting activity. And this is commonly a precursor to additional attacks. And this isn't happening on an insignificant level. On February 17th of this year, about 2.89% of the emails that Talos observed sent from GitHub were likely associated with this campaign.

Speaker 1:18

With us today is the author of the blog, Diana Brown, to help us go more in depth about what's happening, how attackers are getting away with it, and what you need to do to keep your employees and organization safe. Diana, how are you doing?

Diana Brown 1:34

Hi, Amy. Thank you for having me. I'm good. Thank you.

Amy Ciminnisi 1:38

Great. Well, thanks for joining. Can you talk a little bit about how your team originally noticed that this was happening? What was Talos seeing on our end, and how did we identify that this was something that was occurring?

Diana Brown 1:51

Well, that's a great question. And it really gets to the heart of how we work here at Talos. The email security research team, which I'm part of, uh, has been doing some incredible work this past year, keeping a really close eye on how these SaaS platforms are being abused. A huge part of this effort involves diving deep into the suspicious emails our customers submit to us. Since we have this huge bird-eye view of global email traffic, we are constantly on the lookout for patterns. When we started cross-referencing those customer submissions with our uh broader telemetry, we saw a pattern emerging. The red flag wasn't on the authentication side, as you mentioned, it was the content. We were seeing these scammy lures inside emails that, from authentication point of view, were clean. They have valid SPF, DKM, DMARC headers. They were coming from verified, trusted IP ranges. But when you see urgent financial billing notifications coming out of a code repository or fake support numbers coming from a project management board, that's a massive red flag. It was that disconnect where the delivery was legitimate, but the intent was clearly malicious that let us identify this uh as a coordinated campaign rather than just a bunch of uh isolated spam.

Amy Ciminnisi 3:29

So I will say that I am very ignorant of how GitHub and Jira's platform infrastructure works, you know, the inner workings. Um are attackers actually entering into privileged accounts within the platforms to send the emails, or are they using like similar or cloned infrastructure that's able to trick the security, email security? What's allowing attackers to use it to send these emails?

Diana Brown 3:59

Well, that is a really important distinction to make. To be clear, the platforms themselves, GitHub and Atlassian, are not compromised. The attackers are not breaking into privileged corporate accounts. Instead, they are doing something much more clever. They are essentially living off the land by using the platforms exactly as they were designed to be used. The attackers simply sign up for a legitimate account, create a repository or set up a project just like any other user. When they push a commit or send an invitation, the platform's own back-end infrastructure generates the email notification. Because the email is dispatched from the platform's own servers, it carries the valid DKM signature, it passes SPF and DMARC checks, and it originates from a trusted verified IP address. In our industry, we've started calling this a platform as a proxy or PAP attack. The platform is essentially acting as a proxy for the attacker. When the email security getaway inspects that message, it sees a perfectly authenticated email from a trusted source, so it lets it through. So it's not an exploit of the platform's code. It's an exploitation of the platform's reputation. But the attackers have figured out that if they can get their malicious content inside the wrapper of a trusted system, they can bypass the primary uh gatekeepers of email security. They aren't trying to trick the infrastructures, they are using the infrastructure to trick the human.

Amy Ciminnisi 5:36

In the blog, we talk about how this campaign is quite dangerous because it exploits the trust that organizations' security systems place in traffic from these vendors or in or these SaaS providers. Um, it also though exploits the human trust that employees are placing in these emails. And personally, when I think of all the emails that I get from GitHub and Jira, you know, if I weren't in a security organization like Talos, like if I were working in an educational technology company, I probably wouldn't put so much scrutiny on those. I'd you know trust that they were coming from the actual platforms and I'd treat them as urgent. Um so, Diana, in the blog you talk about the GitHub campaign and how it primarily abuses the notification pipelines. Um, can you walk me through the GitHub campaign where the threat actors are uh what the threat actors are doing there and what the emails typically look like?

Diana Brown 6:45

Sure. When we talk about GitHub campaign, we are really looking at the weaponization of a platform's commit notification feature. Think of it this way GitHub is designed to keep developers in the loop. When a commit is pushed to a repository, the system automatically fires off an email to everyone watching that project. It's a standard, expected, and um highly trusted workflow. The attackers are abusing how that notification is constructed. In GitHub, when you push a commit, you have two specific fields: the summary, which is a single-line field. Attackers uh we notice that are using it to craft the hook, the subject line that needs to grab your attention immediately. And then the second one is the description. This is a multi-line field, is that's where they put the body of the scam, the fake billing details, the fraudulent support numbers, the scam text itself. When the attacker pushes that commit, GitHub's backend takes those two fields and wraps them in their standard, branded, and cryptographically signed email template. To the recipient, it looks exactly like a system-generated alert from GitHub because that's what it is. And because the email is dispatched from their GitHub's own infrastructure, the headers are perfect. The email security getaway sees an email coming from an authorized GitHub server, so it doesn't even trigger a suspicious flag. And that's where the trust paradox comes in. If you are a developer or someone who works with these tools on a daily basis, you are conditioned to trust these alerts. So even when you see an email that says urgent invoice or um action required billing support, your brain doesn't immediately think, oh, phishing. The attackers are essentially hijacking the reputation of the platform to bypass the technical filters and then using the urgency of the allure to bypass the human discernment. It's a very low-friction way to get a malicious message directly into the inbox. That's why we need to stop and think. Why am I receiving this email from this platform?

Amy Ciminnisi 9:07

Yeah. So how does the Jira campaign differ then? Can you walk us through that one?

Diana Brown 9:13

Yeah, while um GitHub is about abusing the code pipeline, Jira is about abusing invitation logic and uh business critical workflows. Basically, the attackers are tailoring their approach based on the platform specific language or utility. In Jira, the attacker isn't pushing a code. They are setting up a Jira service management project. They create projects with deceptive names and descriptions, then use the platforms to invite victims to these so-called projects. They give uh project a name that sounds official, something like corporate billing or um internal IT support. And then they use the platform's build-in invite customers feature. When they trigger that invite, it takes the attacker's input, that's Cami Hook, and it injects that data into Atlassian's own standard, again, cryptographically signed email template. The result is an email that looks like a perfectly branded professional system alert. It has the correct Atlassian footer, the right branding, and it comes from a trusted Atlassian domain. The reason this is so effective is that Jira is a business critical tool. In most organizations, an email from Jira is seen as a signal that someone needs your input on a project or that IT needs you to act on something. So employees are preconditioned to treat this as legitimate, safe, and many times urgent. So while GitHub is about exploiting the developer's trust, Jira is about exploiting the employees' administrative trust.

Amy Ciminnisi 11:08

So if you're an employee and you are getting these emails, what should you be on the lookout for? Um, you know, just uh is it are are they your typical run-of-the-mill, you know, phishing emails uh other than the headers and like it coming from a legitimate source? What's is is there anything about the body or the content of the message that they should watch for?

Diana Brown 11:34

Yes, the content of the message, is it congruent with your role? Is it congruent with your activity on that platform? Is it something that you are working on? If not, definitely is not it's it's something fishy, it's a red flag. Uh we as defenders for this specific platform abuse emails, we have to move from that old binary approach where we just block or allow based on domain's reputations because the attackers are using the platform's own infrastructure, the getaway is essentially blind.

Amy Ciminnisi 12:15

So, from a security perspective, obviously this is a lot more complicated than just adding them to a block list because this is coming from a legitimate source. In the blog, you talk about how we need to be inserting contextual awareness to our defenses. Um, and you give five recommendations for defenders to mitigate these threats. Let's walk through them. First, you talk about identity and instance level verification and how this is moving from global domain trust to instance level authorization. Uh, what does this mean?

Diana Brown 12:54

Instead of just trusting any emails from these platforms, we need to verify that the notification is actually mapped to our own internal SAS directory. If it's not coming from our specific verified instance of that platform, it shouldn't be trusted.

Amy Ciminnisi 13:11

So next we talk about upstream API level monitoring.

Diana Brown 13:15

To really get ahead of these attacks, uh, we have to move our focus by monitoring the platforms themselves. Um pulling audit logs from tools like GitHub or Jira directly into the CM, we are not waiting for an email to arrive. We are actually watching the attacker set up the trap in real time. When we are actively watching those logs, we can spot the precursor move. Like someone creating a project with a suspicious name or mass inviting people at 3 a.m. in the morning from a weird location where your business doesn't even have employees. Yeah. Once that behavior, we can trigger an automatic response to shut down the account or block the project before it even sends out a single notification.

Amy Ciminnisi 14:04

The next recommendation you mentioned was to replace simple keyword matching with business logic profiling. So what is that?

Diana Brown 14:14

This is where we apply that semantic discontinuity that we just talked about. We need to define a communication baseline for our tools. GitHub is for code, Jira is for project management. If you receive an urgent billing notification from a code repository, your security stack should flag that as incongruent with the platform utility and block it.

Amy Ciminnisi 14:36

And then... mitigating cognitive automation fatigue. Um, automation fatigue, I'm sure every person listening to this is well aware of what that is. Um, can you talk a little bit more about what that means from you know the organization side?

Diana Brown 14:54

We also have to add friction. Attackers rely on reflexive trust, the habit of clicking uh links because the email looks official. We need to introduce friction for high-risk actions. If you get an invite to a new project, policy should mandate you to navigate directly to the official portal rather than clicking uh link in the email. So it breaks the cycle of reflexive clicking.

Amy Ciminnisi 15:21

And then we talk about making the attack expensive.

Diana Brown 15:26

We should integrate our security response tools with the provider's abuse APIs. So when we identify a malicious repository or a project, we should be able to report it instantly to the provider's trust and uh safety team. The goal is to force the attacker to constantly burn and rebuild their infrastructure until the campaign is no longer economically uh viable for them.

Amy Ciminnisi 15:54

Yeah. And so this is we've we've talked about the technical side and how to defend against these specific campaigns, but I want to zoom out for a second. Um as we've talked about, this is a huge challenge to the trust that we put in our everyday SaaS tools. Um, it makes me think a lot about the rise of living off the land binaries. Um, do you think that we're heading toward a future where we have to treat every single notification from these platforms with the same levels of suspicion as like a random email from an unknown sender? Um, and do you think like we're going to actually be able to reclaim that trust, or is this a new normal that we have to learn to deal with?

Diana Brown 16:47

That is the big question, isn't it? Yeah. Regarding platform abuse, uh, we are definitely at the end of the era of binary trust. We are moving away from trusting the source toward trusting the behavior, the user role, the platform's functional uh baseline, and the specific action that is being performed. We are moving toward what I call a zero trust SaaS model. That doesn't mean we stop using these tools that's um impossible. We they are the backbone of how we work. It just means we stop trusting the infrastructure by default and uh start verifying the intent behind the communication. Bottom line is that we are shifting from a reactive mindset, is this email authenticated, to a proactive mindset? Is this platform activity authorized and consistent with our business logic? It's a process, we'll take some time to build it, but it will keep us safe in the long run. Now, um at Talos, we've always had powerful content detection tools in our arsenal. We've always been able to dig into the message body rather than just checking the envelope. But with these uh platform abuse campaigns, uh we've been um aggressively tuning um and uh evolving a multi-layer defense that looks at uh who, what, and why. It's a deep-level inspection to catch that um semantic discontinuity that I mentioned earlier. When you zoom out and look at the bigger picture, like uh how effective this living of the land strategies are, it's easy to feel like this is just the new normal we have to live with, but um I don't think we just have to accept it. New normal sh is an environment where security professionals must treat every automated interaction with a healthy dose of skepticism. Uh, we are heading uh toward the future of a smarter verification. So to wrap things up, the goal isn't to reach a point where the threat disappears, but to reach a point where the cost of attacking becomes so high due to our ability to detect, uh, verify, automate takedowns that the attackers are forced to burn their infrastructure until it's um no longer profitable for them. It's a permanent shift, but it's one that we are actively building the tools to manage.

Amy Ciminnisi 19:31

For security teams who are really spread thin or who have low budget or low headcount, um, what would you say is is the highest priority um with this type of threat?

Diana Brown 19:46

Yes. Um, watch the telemetry, any abnormal behavior, any spikes into the volume of the activity of of those platforms, and essentially look at the content. Content, content, content.

Amy Ciminnisi 20:03

I think that wraps it up for this episode of Talo Takes. Diana, thank you so much for joining. It was really great to you know hear you speak more in depth about this this really awesome article that you put together. So thank you.

Diana Brown 20:17

Thank you so much for having me, and thank you so much to my email security research team that helped me do this research.

Amy Ciminnisi 20:24

Yeah, we we have some awesome people here at Talos. Everyone, thank you so much for listening. I will put the blog in the show notes. So please go and read that. It's really fantastic. We will see you next time on Talos Takes. Thanks and stay safe out there.