URL filter blocking the domain "atlas-trk.prd.msg.ss-inf.net"

[jeff.schuelein]

As of today our email security application is blocking access to the following domain redirect "atlas-trk.prd.msg.ss-inf.net" as spear-phishing, after clicking on view request from an automated Jira ticket email. Can someone tell me what this URL redirect is for and whether it is safe? Thx

[Andy Heinzer · Accepted solution]

Hi @jeff.schuelein 

Sorry for the inconvenience here.  Yes I can confirm that this URL is legitimately used by our Cloud messaging services.  However it appears that new domain was not yet included into the official domains and IP ranges documentation.

It appears that the feature flag that enabled this change has been rolled back for now (within the last day and it can take some time to take affect in all environments) So perhaps the update to documentation might not be coming so quickly.  However my understanding is that this change is being reverted as of now.

[Martin Kaul]

sorry, I can't believe that atlas-trk.prd.msg.ss-inf.net is an Atlassian domain. It will be blocked by us. Why do not use a address atlassian.net or so...

Best regards

  Martin

[Andy Heinzer]

Hi @Martin Kaul 

We have recently updated the documentation in IP addresses and domains for Atlassian cloud products to include this domain.  This is in fact a domain that Atlassian uses.

[Jan Tymiński]

@Andy Heinzer looks like Atlassian is OK with proceeding with this domain.
I see it as similar move to what a company in Poland recently did.
Security people try their best to learn people to avoid weirdly looking domains by all means and here you come acting like it is perfectly fine to use a weirdly looking domain in production.

Has Atlassian thought about something like social responsibility?

I completely understand @Martin Kaul and if I would be the one to manage deny list of domains, this one would land there regardless of being legitimate.

Did the company consult that idea with internal security team?

[Martin Kaul]

Hi @Andy Heinzer 

I agry to @Jan Tymiński 

It is not the point that this address is a valid address from Atlassian. We sensitize our people not to click on cryptic links. When the domain is atlassian.com then its readable and understandable. But "atlas-trk.prd.msg.ss-inf.net"??? A potential hacker only needs to change one character of ss-inf.net for example to ss-int.net - and then the people click the link.

An other point is, that Atlassian is not the only company with Messages send to us. What should we do? Read URL documentation of all of our connected companies to get the list of all valid domains of the companies?

No, No, when Atlassian want to send us Messages with valid links, then do not use links with cryptic mysterious domains - use your valid and (important) readable company domain.

best regards

  Martin

[Christian Sorbello]

Update:

I raised a support ticket with Atlassian who advised this is an intentional change, although they have not yet updated their IP Addresses page... IP addresses and domains for Atlassian cloud products | Atlassian Support.

[Jan Tymiński]

Great.

So Atlassian is cool to go against the grain.

All the security trainings train people not to click strange-looking URLs and Atlassian introduces one as a legitimate URL (when a truly legitimate URL could be used instead) and will start teaching all these people to stop worrying about such URLs.

Atlassian, you can do much better and I expect you revise this approach and improve here.

This way you're contributing to lowering global security in the times where it gets extremely important to do everything to improve it.
Please take a couple of minutes, meet there internally and discuss this approach and an option to generate genuinely looking urls.

If there's `customer.atlassian.net` available for the `customer`, everyone at `customer` should get URLs starting with `customer.atlassian.net` within the spaces of the `customer.

I hope my point here is clear why it is important to not use urls like `blah-blahblah.blah-some.random-gibberish.unrelated-to-atlassian.net`

[Christian Sorbello]

Following.

This also started happening to us today. Emails are being blocked by our filter.

Can anyone confirm the validity of the domain and what has changed?

[Steve Smith]

We have end users also getting this URL being used.

https://atlas-trk.prd.msg.ss-inf.net/f/a/

Is this a valid Atlassian url?

[Raimo Neumann]

@Steve Smith & @Jan Tymiński , same here!

Years of cyber security awareness training got our employees to finally be more careful with e-mails and an ever rising threat due to conflicts in Ukraine and the Middle-East.

Now they're reporting (supposedly) Atlassian-E-Mails containing URLs using, https://atlas-trk.prd.msg.ss-inf.net/f/a, which, in every sense of cyber security training success, is correct. 

If I'm reading @Andy Heinzer's answer above correctly, this is a legit domain for Atlassian Cloud Services (such as Confluence). However, it would be great to have that confirmed for this type of e-mail before releasing it to our employees.

Sender-domain is id.atlassian.net.

Thanks heaps in advance! 

[Andy Heinzer]

Hi @Raimo Neumann I reached out to my internal team about this.  They have confirmed that this domain is owned and operated by Atlassian.  This new address does not yet appear within the documented list of IP Address Ranges and Domains for Atlassian Cloud products, however I have also reached out to my documentation team to update that content.

[Raimo Neumann]

Thanks heaps for confirming @Andy Heinzer! 🙌🏼

[Dave Rosenlund _Trundl_]

Welcome to the community, @jeff.schuelein  👋

I cannot find any information about this happening anywhere or to anyone else. So, I suspect you'll need your email security vendor's help here or the administrator of that system or service to whitelist that address.

However, given the urgency, I will escalate this thread to Atlassian support to see if they can provide helpful guidance.

Good luck,

-dave

[jeff.schuelein]

Thanks for the quick reply. I was able to whitelist the domain in order to prevent further issues in our environment. I was mostly curious what it was doing and if this was the new norm when opening Jira ticket links within our emails. Thx