How I Mapped the Hidden Attack Surface of a Major Food Delivery Platform

Security assessments rarely start with a zero-day exploit or a dramatic breach. They start with curiosity, a terminal, and the question: what did they forget to protect?

During a study-driven security assessment of a major European food delivery platform, I discovered that while the primary domain was heavily fortified with Cloudflare WAF and bot mitigation, several subdomains resolved to completely unprotected origin servers sitting in the open. No WAF. No rate limiting. No bot protection. Nine open ports on one of them, including plaintext email services.

This post walks through exactly how I found it all, what the implications are, and what I recommended to fix it.

The Starting Point#

The platform's main website was well protected. Cloudflare WAF in front, PerimeterX bot management, proper security headers. On the surface, everything looked solid.

But modern web platforms are not a single server. They are ecosystems of subdomains, third-party integrations, CDN edges, email services, and internal tools. The main domain might be locked down, but every subdomain is another door. And doors get forgotten.

Methodology: How I Mapped the Attack Surface#

The entire assessment used passive, non-destructive techniques. No exploitation was attempted. No data was accessed or modified.

Step 1: Subdomain Enumeration via Certificate Transparency#

Certificate Transparency (CT) logs are a goldmine for reconnaissance. Every publicly trusted TLS certificate is logged, and services like crt.sh let you search those logs by domain.

A single query against CT logs revealed over a dozen subdomains with issued certificates, including:

• HR and recruitment portals
• Merchant management portals
• Action logging endpoints
• Email delivery infrastructure (SendGrid CNAME records)
• Career pages
• A rider hub that had been decommissioned but still had a certificate on record

Some of these pointed to the main Cloudflare-protected infrastructure. Others pointed somewhere else entirely.

Step 2: DNS Resolution and Origin Discovery#

For each subdomain, I resolved the DNS records and traced CNAME chains. The pattern that emerged was telling:

• Main domain and career pages: Cloudflare IPs (104.x.x.x, 172.x.x.x) with proper WAF protection
• HR subdomain: CNAME chain leading to a third-party shared hosting provider in the same country, resolving to a single IP with no CDN or WAF
• Action logging subdomain: AWS Elastic Load Balancer in us-east-1
• Merchant portal: Shopify hosted
• Email link tracking subdomains: SendGrid, resolving to AWS infrastructure across two EU regions

The HR subdomain was the most concerning. The CNAME chain went: hr.[target].com to [vendor].com to a bare IP address. That IP was a shared hosting server operated by a local HR software vendor.

Step 3: Port Scanning and Service Identification#

A TCP port scan of the HR server revealed nine open ports:

Nine ports. Seven of them with security implications. On a server that was supposed to handle HR and recruitment data for a company serving millions of customers.

Step 4: Banner Grabbing#

Connecting to each open port and reading the service banners revealed additional information:

SMTP (port 25): The banner disclosed an internal hostname belonging to a completely different domain, confirming this was a multi-tenant shared hosting environment. The food delivery platform's HR data sat on the same server as unrelated third-party services.

IMAP (port 143): The IMAP service advertised AUTH=PLAIN and AUTH=LOGIN mechanisms before any TLS negotiation. This means an attacker with network positioning (same Wi-Fi, compromised ISP, BGP hijack) could intercept email credentials in cleartext. While STARTTLS was offered, it was not enforced before authentication, making downgrade attacks trivial.

POP3 (port 110): Similar to IMAP, the POP3 banner exposed the internal hostname and accepted plaintext authentication.

FTP (port 21): Anonymous login was rejected (I verified), but the port accepted connections from any IP with no rate limiting observed.

Step 5: Security Header Audit#

Comparing HTTP response headers between the protected main domain and the exposed HR subdomain told the full story:

Every single standard security header was missing. The server was vulnerable to clickjacking, MIME-type confusion, and lacked all browser-level security controls.

Step 6: Virtual Host Enumeration#

The nginx server on the exposed IP responded with different content depending on the Host header. By testing various hostnames, I could enumerate all domains hosted on that server:

• The HR subdomain returned a vendor-branded 404 page
• A jobs subdomain returned a different page on the same server
• The main domain name, when sent as a Host header to the origin IP, returned an "Under Construction" page with a JavaScript redirect to the hosting vendor
• The page contained developer metadata in HTML meta tags, including vendor contact emails and related domain names

This confirmed the shared hosting nature and exposed the full vendor relationship.

Step 7: Cloud Infrastructure Analysis#

The action logging subdomain resolved to an AWS Elastic Load Balancer. Interesting findings:

• The response header Server: awselb/2.0 confirmed the exact infrastructure component
• FTP (port 21) was open on the load balancer, which is unusual and suggests a misconfigured Security Group
• Certificate transparency logs showed the same infrastructure had previously been associated with another brand in the same corporate family, confirming shared backend services across brands and regions

The merchant portal, hosted on Shopify, leaked extensive internal details through the server-timing response header: database query timing (useful for timing-based side-channel attacks), internal server identifiers, the client's ASN, the exact GCP datacenter region, and Shopify theme IDs.

Findings Summary#

Overall CVSS 3.1 Base Score: 7.5 (High)

The Infrastructure Map#

What emerged was a clear picture of fragmented security posture:

[PROTECTED - Behind Cloudflare WAF + Bot Mitigation]
    Main website ---------> Cloudflare Edge -> Protected Origin
    Career page ----------> Cloudflare Edge -> Protected Origin

[UNPROTECTED - Directly Exposed to Internet]
    HR portal ------------> Shared hosting server (9 open ports)
    Jobs portal ----------> Same shared hosting server
    Action logging -------> AWS ELB (FTP open, version disclosed)

[THIRD-PARTY HOSTED]
    Merchant portal ------> Shopify (GCP, leaking server-timing)
    Email tracking -------> SendGrid (AWS, two EU regions)

The protected surface was solid. The forgotten subdomains were wide open.

Realistic Attack Scenarios#

Based on these findings, several attack paths become viable:

Credential stuffing on email services: The open IMAP/POP3/SMTP services accept connections from any IP. An attacker could run automated credential stuffing using leaked credentials from previous breaches. If any HR staff reused passwords, the attacker gains access to recruitment emails containing candidate personal data, salary information, and internal hiring decisions.

Email interception via STARTTLS downgrade: A network-positioned attacker intercepts IMAP traffic on the plaintext port where AUTH=PLAIN transmits credentials in base64 encoding. Without enforced TLS, the connection can be downgraded.

Shared hosting lateral movement: The server hosts multiple tenants. Compromising any other tenant on the same server could give access to the delivery platform's HR files, databases, and email.

Phishing via SMTP abuse: If the SMTP server accepts mail for the target domain without proper authentication, an attacker can send emails that appear to come from legitimate company addresses, bypassing many email security filters.

Recommendations I Submitted#

Immediate (within 48 hours)#

1. Put all subdomains behind the existing WAF or remove unused DNS records entirely
2. Close ports 21, 25, 110, and 143 on the HR server
3. Enforce STARTTLS before accepting any authentication on IMAP; ideally disable plaintext ports and use only encrypted variants (993/995)

Short-term (within 1 week)#

4. Review the third-party hosting arrangement for the HR portal. Shared hosting for HR data of a platform serving millions of users is a supply chain risk
5. Close FTP on the AWS load balancer by tightening the Security Group
6. Add security headers (HSTS, CSP, X-Frame-Options) to all subdomains
7. Strip sensitive fields from server-timing headers on the merchant portal

Medium-term (within 1 month)#

8. Audit all subdomains in DNS and CT logs, remove records for decommissioned services
9. Migrate HR services to a dedicated, hardened server with WAF protection
10. Implement rate limiting on all exposed authentication endpoints

What I Learned#

This assessment reinforced something fundamental: security is only as strong as the weakest subdomain. Organizations invest heavily in protecting their primary web presence, but subdomains hosting HR portals, internal tools, and third-party integrations often get overlooked.

The most critical finding was not a sophisticated exploit. It was a forgotten subdomain pointing to a shared hosting server with plaintext email services exposed to the entire internet. No complex tooling needed. Just DNS queries, port scans, and reading service banners.

For anyone studying network security, this is the kind of real-world assessment that textbooks describe but rarely walk through. The tools are simple: nslookup, curl, TCP connection testing, and certificate transparency searches. The skill is knowing where to look and understanding what the responses mean.

Disclosure#

All findings were reported to the company through their official vulnerability disclosure program. The assessment used only passive, non-destructive reconnaissance techniques. No exploitation was attempted. No data was accessed, modified, or exfiltrated. No authentication was bypassed. No denial of service was caused.

This writeup is published for educational purposes as part of my university coursework in network security. The target company has been anonymized. Specific IP addresses, domain names, and identifying details have been redacted.