Path of least resistance: Why would attackers be keener to exploit a weakly-configured subdomain than a strongly-fortified production domain?

Cybersecurity teams tend to put the best brainpower, best security tools into securing their production domain. After all, production domains (usually designated as www.example.com) carry the organization’s production traffic, which are definitely high-value targets that deserve great care and attention from the cybersecurity team.

However, let’s step into the shoes of the malicious attackers for a while. They do expect the defenders to secure the production system as water-tight as possible. Instead of doing a head-on attack against the strongest link, why not penetrate into weaker links, those weakly-configured subdomains, first, and then move one’s way up to the crown jewel production systems? This kind of land-and-expand strategy usually is the path of least resistance, particularly for internal networks lacking micro-segmentation.

In this cloud computing era, many sub-teams might spin up new subdomains any time when business needs arise. Before long, it is easy to lose track of the precise attack surface of your organization’s subdomains. Some common example subdomains include:

cms.example.com

wordpress.example.com

drupal.example.com

api.example.com

images.example.com

videos.example.com

staging.example.com

preprod.example.com

etc.

There are cybersecurity tools, such as Sublist3r, which can help your team to enumerate and probe for subdomains:

This can help your cybersecurity team to monitor the evolution of your subdomain attack surface.

In the field, we constantly observe cybersecurity team spent all their time and effort in the production system, while subdomains security are being ignored, which is definitely a grave mistake. A recent example from a retailer:

The retailer’s www.example.com is well-fortified, running HSTS and TLS 1.3, and got all the ticks from standards such as PCI-DSS.

Yet, its content management subdomain is running on HTTP only! It is not even Akamaized in this particular anonymized example.

As you can see from Chrome’s “Not Secure” warning tab, this CMS is running on HTTP for username / password login, and ISP engineers are likely to see plain-text password in the wire. This echoes back to our earlier speculation that such a weakly-configured subdomain is definitely an easier target for penetration and thus a path of least resistance. Once the attacker gains a foothold in the CMS, they do further penetration such as implanting malware or implanting malicious JavaScripts, which can lead to infecting other systems or causing PII leakage.

In a nutshell, to combat the risk from weakly-configured subdomains, some cybersecurity tools Akamai can offer to help:

  • Website security assessment: Apart from checking the production website’s security posture, our consultant will also probe for subdomains who might be living in the shadows, which could become a weaker link to your attack surface.
  • Guardicore: A micro-segmentation tool which can block malware from doing their land-and-expand, essentially stopping malware in infected subdomains from moving up to the crown jewels of your system.
  • CMS and other internal tools subdomains would find Enterprise Application Access helpful, via which Akamai can front the systems with Enterprise SSO and HTTPS, without requiring any complicated inbound firewall changes. Essentially, EAA transforms these internal tools subdomains into systems that conform to Zero Trust Network Access paradigm.
  • API subdomains can be safeguarded by API Security
1 Like