The Law Firm's Website Was Working Fine. It Was Also a Backdoor Into Dozens of Other Businesses.

The short version

A law firm engaged Stealth Cyber to conduct a penetration test of their website as part of a broader security review. The website was functional, up to date, and appeared well maintained. However, the underlying shared hosting server was misconfigured in a way that turned it into an open proxy. This meant anyone who could access the server could route traffic through it to reach other systems, including every other website hosted on the same server.

The law firm's website was not just a potential target. It was a potential launchpad.

What we were asked to do

The firm had recently reviewed their cyber insurance requirements and identified the need for a technical assessment of their external-facing assets. Their website was the primary one. Stealth Cyber was engaged to perform a targeted penetration test against the site and its hosting environment.

What we found

The website itself was running a current CMS version with no critical vulnerabilities in the application layer. The hosting environment was a different story.

The site was hosted on a shared server managed by a third-party web hosting provider. During testing, Stealth Cyber identified that the server was configured as an open proxy. This is a server-level misconfiguration that allows external requests to be relayed through the server to other destinations.

First, the server could be used to proxy traffic to external targets. An attacker could route requests through the law firm's server to mask their origin. This means that if the attacker launched a phishing campaign, scanned other networks, or attempted to exploit other systems, the traffic would appear to originate from the law firm's IP address. The law firm would bear the reputational and potentially legal consequences.

Second, the server could be used to access other sites hosted on the same infrastructure. Because this was a shared hosting environment, the open proxy configuration gave access to internal network paths that connected to other customer environments on the same server. This means an attacker could potentially reach databases, admin panels, and file systems belonging to completely unrelated businesses.

The law firm had no visibility into this configuration. Their web developer had not flagged it. The hosting provider had not identified it. It had likely been in place since the server was provisioned.

Why this happens

Shared hosting is common for small and mid-sized businesses because it is inexpensive and simple to set up. The hosting provider manages the server, and the business focuses on their website content. The problem is that shared hosting places multiple unrelated businesses on the same server, and the security of that server depends entirely on the hosting provider's configuration.

In this case, the hosting provider had not properly restricted proxy functionality at the server level. This is not an obscure or difficult attack to execute. Open proxy detection is a standard check in any competent penetration test. The fact that it had gone undetected suggests that no meaningful security testing had been performed on the hosting environment before Stealth Cyber's engagement.

This is a systemic issue. Many businesses assume that their hosting provider is managing security on their behalf. In practice, most shared hosting agreements place the responsibility for application-level security on the customer, while server-level security depends on the provider's diligence. Neither party may be actively testing or monitoring.

What this means if you've outsourced your website

If your website is hosted on a shared server, the security of your site depends on the security of every other site on that server, and on the hosting provider's server configuration. You may have a perfectly maintained website, but if the server it sits on is misconfigured, your business is exposed.

A penetration test of your website should include the hosting environment, not just the application. Testing only the website itself is like checking the locks on your office door without checking whether the building's back entrance is propped open.

If you do not know what type of hosting your website uses, who manages the server, or when it was last tested, those are the first questions to ask.