Open Source SaaS Reconnaissance Utilizing Subdomains
Investigations into enumeration of an organization's SaaS tooling
On a recent Purple Team engagement, I was accessing the client’s Splunk cloud instance. Being my normal typo-filled self, I fat fingered the URL and went to clieent.splunkcloud.com instead of the correct client.splunkcloud.com. Instead of being redirected to the login portal, I received a DNS resolution error, fixed the typo, and moved on. A little while later, I was thinking about the typo again and wondered how this information leakage could be utilized by an attacker. To backup a little, a key part of an offensive campaign (and many say the most critical part) is recon. During this phase, the Red Team or malicious actor tries to obtain as much information about the target as possible. Key items of interest include organizational charts, employee lists, email formats, external address space, and technologies utilized by the organization. During this phase, the attacker wants to limit their interaction with the target as much as possible in order to avoid tipping off defenders. Most attackers avoid active scanning or interaction with the target during this phase.
So back to my story. I wanted to answer two questions: 1. Could this technique be applied to identify other organizations that are using Splunk Cloud? 2. What other SaaS applications could I enumerate in this way?
To answer the first question, I pulled a CSV of the Fortune 500 companies and ran a very rudimentary bash loop to curl sites based on the company names.
while read p; do echo $p; curl $p.splunkcloud.com; done < ~/f500.txt > ~/f500_splunkcloud.txt
Surprisingly, this returned 29 results. I then built a better wordlist for the first 150 companies and compared that with what was returned for the top 150 from the basic list. As an example, for “Capital One Financial”, my first list only contained “capitalonefinancial”. In the second list, I also included “capitalone”. This yieled 14 companies in the top 150 utilizing slunkcloud.com whereas the basic search had returned only 9 in the top 150. My basic search of the Fortune 500 yielded 29 companies using splunkcloud.com, though I’m sure that would return more results if I built a better wordlist.
My next goal was to see if this worked for other SaaS applications. In a few minutes of digging, I identified that Okta, Zoom, Atlassian, Slack, Box, and Zendesk also offer the same opportunities for open source recon (I’m intentionally avoiding the word “vulnerability” as I don’t believe this qualifies). A few of these sites were a bit more difficult to figure out. As an example, entering an invalid Okta url will still land you on a valid sign-in page. Fortunately, most organization upload their logo when making an Okta login page and we can grep for logoText and identify which of these pages are actually valid.
while read p; do echo $p; curl -L $p.okta.com | grep logoText; done < ~/top150.txt > top150_okta.txt
Utilizing my same top 150 list with some adjustments, I found that 31 of the top 150 Fortune 500 companies are using Okta. (Some false positives may be in there.)
For Slack, I simply had to look for the phrase “There’s been a glitch” which was returned on invalid subdomains. My list yielded quite a few false positives so I had to grep based on email addresses to ensure I had the right organization.
while read p; do echo $p; curl -L $p.slack.com | tr -d ‘\n’ | grep -v “There’s been a glitch” ; done < ~/top150.txt > top150_slack.txt
cat top150_slack.txt | grep -o ‘data-team-email-domains-formatted.{0,30}‘
I’d like to give a special shout-out to the folks at 1password.com. As far as I could tell, valid and invalid login pages presented the exact same content.
So what should you take away from this? As an attacker, build a list of SaaS applications to check prior to each engagement and add that to your playbook. As a defender, unless the vendor makes changes, I don’t see many options for preventing this type of recon. I’d be happy to receive emails if you have ideas. Make sure to monitor for logins to all your SaaS applications. Utilize a robust IAM solution. You could also consider setting up honey services. Say your a Microsoft Teams organization (some do exist, trust me), you could register for a basic Slack account and monitor for attempted logins. I haven’t done the research, but I’d bet that most failed logins would likely be a part of an advanced campaign as opposed to merely bots.
If you have experience in this area (either defending against this or using it on your Red Teams), I’d be happy to hear your stories!
All opinions in this article are my own.
Update: I felt like this work needed a POC and I wanted to practice some basic Go, so I coded this up! I added a few more SaaS applications (SalesForce and Adobe Creative Cloud) and removed Zendesk as I felt there were too many false posities. Check it out https://github.com/daniel-infosec/subsaas.