Phishing is an ever-present threat, but lately, user education and spam filters have helped mitigate some of that threat. But what happens when a phish makes it further than the user’s mailbox and deeper into your own environment? Can users be expected to have the same level of caution?

The event covered in this post is a real event that I discovered while hunting through O365 logs for our SOC customers. For the sake of clarity throughout this blog post, I’m going to refer to Microsoft 365 as O365, since that is how our log fields are currently labeled. I will also be redacting the email domains, so I’ll refer to the customer domain as “customer.com” when necessary.

When I first discovered this event, I was looking for emails that O365 had marked as phishing but still delivered (rather than blocked or quarantined). There could be a few reasons for this occurring, like a retroactive phishing verdict or an exception for certain mailboxes.

o365.audit.Verdict: “Phish” and o365.audit.DeliveryAction: Delivered

What I found was quite a lot of spam emails that were related to marketing. O365 was marking tens of thousands of emails as phishing simply due to spoofed sender addresses by email marketing services. This is fairly common as you want your recipients to see your own email domain as the sender rather than the domain of the service you’re using to send these emails.

To narrow the results down further, I began experimenting with excluding various field values to narrow down my search results. I’ll spare you the details of my trial-and-error because that is when I found the events that inspired this blog post. Take a look at the screencap of the logs below:

A few important things from that image to take note of:

The P1Sender field is a marketing email service domain
The P2Sender field is actually the customer’s address of [email protected]
The emails are all marked as phishing and have been blocked and quarantined
The O365 policy states that these emails are an “IntraOrgPhish”

To quickly explain the difference between P1Sender and P2Sender, the P1Sender is the “MAIL FROM” address which, in simple terms, can usually be understood as the true sender of the email. The P2Sender is the “From” address which is displayed in your email client as who the email is from. In this example, the accounting email address of the customer is being spoofed as the From address. This is also likely the reason for the marking of “IntraOrgPhish.”

Now, hopefully having understood that, we shouldn’t be terribly worried. All these emails were blocked and quarantined. Looking at the sender addresses, it doesn’t look like a true intra-organizational phishing attack, so all seems fine. Later on, we can pull the emails if we want some artifacts, but otherwise, there’s nothing requiring much of a response here, given how commonplace phishing emails like this are.

However. Due to my morbid curiosity, I dug a little deeper and found this:

A number of these emails were sent to an Atlassian email linked to a Jira project, and these emails were not blocked or quarantined even though they were classified as phishing. Rather, they were marked as outbound spam. But what is the difference here? I’ll give you a hint — it’s not either of the sender addresses. The P1Sender stays as the same email marketing domain and the P2Sender is still [email protected]. So why the different response from O365?

It turns out, this accounting email address is, unsurprisingly, an email distribution list for the company in question, and this email distro has a member that is an “Exchange Contact” for forwarding and creating issues in Jira. This Exchange Contact facilitated the forwarding of these phishing emails to Jira, and with the emails now being outbound rather than inbound, O365 classified these as outbound spam and allowed them through.

This is where things get concerning. These emails were forwarded, malicious attachments and all, to a Jira project, creating Jira issues with those attachments included and attached within Jira. If you don’t quite grasp the weight of this issue immediately, consider this: a user might be hesitant to open an attachment in a random email, but would they be just as hesitant to open an attachment in a Jira ticket assigned to them?

Luckily, we caught this issue quickly, that same day. We were able to have these Jira tickets deleted from the project and created an Elastic detection to alert us of phishing attachments being forwarded to Atlassian. But most importantly, we didn’t find any log events to indicate anyone opened that attachment or visited any of the links within.

To summarize the message of this blog post, I recommend that you carefully review and understand how you forward emails to your ticketing systems — you could very well be phishing your own users. As I mentioned earlier, even someone who is well-educated on the threats of phishing may not expect that phish to be sitting inside of one of their work items.

What can you do about this (besides deleting Jira and returning to sticky notes and carrier pigeons for project management)?

On our side, a member of the BHIS systems team created a service account for one of our own email distros and connected it to our ticketing system. This allows for emails to be pulled from the inboxes, rather than being forwarded to a contact, which seemed to be the root cause of this issue.

If you’re looking for how to do this for Jira, you might find this link helpful: https://support.atlassian.com/jira-service-management-cloud/docs/add-an-email-account/

As a bonus, if you’ve read this far, here is part of what was in the malicious .html file:

As you might have already guessed, the file was a fake login page designed to be a credential harvester. While a cred harvester still might not have tricked a user within Jira, can we say the same if this was a macro-enabled excel workbook? I would prefer not to tempt that fate.

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

Stop Phishing Yourself: How Auto-Forwarding and Exchange Contacts Can Stab You in the Back