Shadow IT Isn’t Invisible - It’s Expanding Your Attack Surface. Here’s Proof
Shadow IT refers to systems developed within an organization which are unknown to the team responsible for security.
Though there may be policies in place to prevent developers from creating systems that end up unmonitored, there are always ways in which systems slip through the gaps. Unfortunately, these hosts are still discoverable to attackers. If you don’t move to discover them yourself, you’re already on the back foot, and even simple weaknesses on those machines will leave you both exposed and completely in the dark.
One important element of the battle against Shadow IT is to have scanners in place which can enumerate subdomains that are in use by your organization. Developers may be able to create new systems and servers at will, but to make web services accessible and secure, they’ll need a subdomain for the host. This is where subdomain enumeration comes in, which is a tool used by attackers to find your systems, but also a tool for defenders to make sure they have everything covered.
This research showcases some real-world vulnerabilities to illustrate how bad this problem can be, by using a public source of information just as an attacker would.
Finding the Targets
We used Certificate Transparency (CT) logs, a public ledger of certificate information, to show that with a free source of information it’s easy to find targets with glaring vulnerabilities exposed to the internet. By using wildcard queries and commonly used subdomain naming conventions, we found a wide range of exposed systems.
We queried for specific keywords like “git”, “backup”, and for popular software names. With just a handful of search terms we already had approximately 30 million hosts to work with.
What We Found After Just a Few Days of Testing
After building a small pipeline of tooling to cut through the noise of millions of hosts, find live systems, and identify applications, we used a combination of fingerprinting techniques and screenshotting to determine which hosts were interesting or likely vulnerable.
Within just a few days, we had identified a wide range of glaring critical weaknesses on public systems, none of which involved advanced exploitation. Sensitive information was simply sitting there, ready for the taking. All we had to do was find it.
All of the example vulnerabilities that follow are real-world weaknesses in publicly exposed hosts. Vulnerability scanning is ineffective if you don't understand what's exposed. Attack surface management solutions like Intruder provide cover on both fronts – helping you uncover hidden assets and then scanning them regularly for vulnerabilities.
Exposed Backups
When initially brainstorming what types of exposures we wanted to look for, backup related search terms were top of the list, as an exposed backup can truly be devastating.
Within the search results we found many instances of backup files exposed to the internet where any user could download them without authentication. Of the domains identified via the CT logs, we took just a small sample of the hosts to investigate further, and found that hosts from that sample contained active credentials and source code. A common thread we found was that backup related domains often listed the directory contents and often contained a backup archive.

This is one of the most basic vulnerabilities any vulnerability scanner can detect, so the implication is that this host is Shadow IT. If it’s not being scanned, it’s invisible to your security team.
This file was a copy of a website’s source code and included a database dump. Within the source code, the developers also made several mistakes, such as using hardcoded sensitive tokens, like credentials to an FTP server.

The credentials to the FTP server within this file were still active at the time of testing. This really showcases just how something as simple as exposing a backup to the internet can open the defences of your estate and allow an attacker to get a foothold onto your systems.
Unsecured Git Repositories
Similarly, Git repositories are often littered with sensitive information, which has been well documented. Even if developers accidentally commit credentials or secret files to a code repository once, they often forget to clear the Git history, and those files will persist in Git indefinitely if they do not.
In addition to this, many businesses will host their own instances of Git servers to maintain control over the proprietary code that powers their business. Below is one example of an exposed Git server which contained code for an LLM marketplace application:

This repository was wide open, and the files did not show good developer hygiene, since it contained secrets for external services, including Redis, Mysql, OpenAI, and more. These tokens were active at the time of testing.
Leaving your code repository wide open on the internet is such a simple vulnerability. And yet – there it is for those that can find it. Just make sure it’s you finding it first, because attackers will have a field day with your systems if not!
Missing Authentication
Admin panels being exposed to the internet protected by a login page is an attack surface issue by itself. But what if your admin panel was sitting on the internet and required no authentication whatsoever?
We found such examples when looking at logging and monitoring software on our sample hosts, which we focused on since they usually contain sensitive information and can straddle logical networks within a business.

We searched for terms such as “elasticsearch” and “logging”. This resulted in a significant number of panels that were exposed to the internet, the majority of which required authentication. However, many instances did not. We also saw that several hosts had been open without authentication for so long that there was clear activity of threat actors (mostly on Elasticsearch instances) along with ransom notes.

Within these exposed systems we saw a wide range of sensitive information such as infrastructure logging details, secrets, application logs (including user generated content), chat bot messages (including responses) and more.

Propagated Misconfigurations
The power subdomain enumeration came into its own when we came across an unusual case affecting a web hosting provider. It was clear that they were propagating vulnerable code across the many businesses that were their customers, because we found 100 vulnerable hosts following the same naming conventions, with the same vulnerability.
Each of these domains exposed a backup file containing the application source code, user files, and a database copy:

We identified that all these websites were managed by a single web hosting provider. If we were to look at each domain individually, we would just see a single vulnerability. However, by using powerful subdomain enumeration techniques, we were able to see the true scope of this exposure and report it to the affected business.
What This Means For Your Attack Surface
This research was far from comprehensive in its coverage, but it only took us a few days of effort to find a large number of highly critical weaknesses.
A determined threat actor could utilize these techniques and scan large swathes of the internet for specific software to attack, which will unfortunately include even systems belonging to smaller organizations that are unlikely to be singled out and targeted. The industry is seeing this happening right now, for example Greynoise have identified patterns where threat actors search for specific devices ahead of a vulnerability becoming public knowledge, such as the recent vulns in Tomcat or Ivanti.
It is critical that you monitor your external attack surface to prevent misconfigurations and accidental exposures from damaging your business. Intruder automatically discovers unknown exposed assets, so nothing slips through the cracks. Once identified, vulnerability scans help catch the kinds of weaknesses highlighted in this research (and more) before attackers do.
Start a free trial or book a demo to take control of your external attack surface today.