Subdomain phishing in SaaS apps

Just discovered another spammy/abusive tactic people use on SaaS apps…

If your app provides subdomains for your customers, like “customerXXX.app.com”, “customerZZZ.app.com” - pay attention to spammers spoofing big company names in that domain, like “skype.app.com” or “quickbooks.app.com” or even “googlechromesupport.app.com” and then sending out phishing emails on their behalf.

just a heads up

2 Likes

Thanks for this warning. It is remarkably timely for me.

A couple of questions:

  • Is this happening to jitbit?
  • What mitigation advice do you have?

Yeah, just found a couple of hundred trial accounts using this tactic…

We added a filter to the trial page that checks for facebook/gmail/quickbooks/etc but not sure that’s going to be enough…

1 Like

Might be worth exporting all the subdomain list to a CSV file, then hiring someone on places like Upwork to go through the list, finding any trademarked names.

Again, a script can only do so much. You could use the human’s input to improve the script for the 2nd round, and so on.

If it is really a problem, you can do the same as DNS registrars and mail providers do:

If a user requests foo.yourdomain.com, check if foo.com (maybe also .org, .net, …) is registered. If yes, request user to do either of:

  • Place a file with specific response to the root of the foo.com domain
  • Or, create a special TXT record in foo.com DNS

Either of these will provide the user owns the domain.

1 Like

Kinda complicated for a trial, huh? :slight_smile:

First, this is a recipe for a case when spammers abuse your service, I.e. there is a problem already. If you do not have this problem, you can give them any subdomain they want.

Second, the verification is only if they want google.myapp.com. If not, easy: they get trial1234.myapp.com

(About late edits I made to this post: How the phones these days manage to auto-corrupt your text after your attention already moved to the next word? Spying - I made my peace with, but this is really annoying!)

One common approach is to place user content on a domain that is different from your content. So if your service is at myservice.com, then you could put user content on subdomains under myservice.io. This also removes certain risks around cookie access. This is just one mitigation step, and if you have a lot of phishers then other steps may be necessary to reduce their ability and desire to use your system.

2 Likes

@jitbit

This subdomain phishing issue has just started happening to Feature Upvote… did your recommended mitigation technique prove to be good enough?

Yep, filtering big company names + some free email hostings works

1 Like

What I do :
1)On signup I ask for company website
2) The email address domain should match the company website domain name
3) I create the subdomain based on that domain. If someone wants to change it, should send a support ticket but it happens rarely

This mitigates:

  1. Free email accounts like gmail, yahoo, etc - doesn’t work well with temporary email domains though
  2. Make sure the email is related to the domain and should also help to avoid this issue as well
4 Likes