Mapping Ethena's Attack Surface: 51 Subdomains and Dangling CNAMEs

This is a walkthrough of how I mapped Ethena's web attack surface for their Immunefi bug bounty program. The goal was to find subdomain takeover vulnerabilities, which Immunefi rates as High ($15K) to Critical ($50K) depending on impact.

I found 51 subdomains, identified the full hosting infrastructure, and discovered dangling CNAME records pointing to decommissioned AWS load balancers. Here's the methodology.

Step 1: Subdomain Enumeration

Starting with subfinder, a passive subdomain discovery tool that queries certificate transparency logs, DNS datasets, and search engines:

$ subfinder -d ethena.fi -silent | tee subs.txt | wc -l
51

51 subdomains on the first pass. This includes production, staging, dev, and internal services. A few highlights:

• app.ethena.fi, claim.ethena.fi — the in-scope web apps
• staging-app.ethena.fi, dev-app.ethena.fi — pre-production environments
• mint-ops.ethena.fi — internal minting operations UI
• private.api.ethena.fi, public.api.ethena.fi — API endpoints
• vestingschedule.ethena.fi — token vesting interface
• conductor.test.ethena.fi, testnet.rpc.ethena.fi — test infrastructure

Step 2: DNS Resolution and Filtering

Not all discovered subdomains actually resolve. Using dnsx to filter live hosts:

$ cat subs.txt | dnsx -silent | tee resolved.txt | wc -l
29

29 out of 51 resolve. The other 22 are potentially dangling — DNS records exist but no server answers. These are the interesting ones for subdomain takeover.

Step 3: CNAME Chain Analysis

The key to subdomain takeover is finding CNAME records that point to services you can claim. I checked every resolved subdomain:

$ for sub in $(cat resolved.txt); do
    cname=$(dig +short CNAME $sub)
    [ -n "$cname" ] && echo "$sub -> $cname"
  done

This revealed the full infrastructure map:

Subdomain Pattern	Provider	CNAME Target
app, www.app, staging-app, dev-app	Vercel	5b0678bd...vercel-dns-012.com
claim, staging-claim, dev-claim	Vercel	fc65a14d...vercel-dns-012.com
www, staging-landing, dev-landing	Vercel	3ae83d51...vercel-dns-012.com
whitelabel, *.whitelabel	Vercel	996e9c27...vercel-dns-012.com
public.api, private.api (+ staging)	Cloudflare	*.cdn.cloudflare.net
gov	Discourse	ethena.hosted-by-discourse.com
docs	GitBook	8487243c64-hosting.gitbook.io
vestingschedule	AWS API Gateway	d-2wnsutvr5e.execute-api.eu-west-1
mint-ops, staging.mint-ops	AWS ELB (dead)	*.ap-east-1.elb.amazonaws.com
dev-network	Vercel (404)	cname.vercel-dns.com

The pattern is clear: Ethena uses Vercel for frontends, Cloudflare for API proxying, and various AWS services for backend infrastructure.

Step 4: Finding Dangling Records

Now the important part. The 22 unresolved subdomains need individual DNS inspection. I checked each one for CNAME records pointing to dead services:

$ dig +short CNAME mint-ops.ethena.fi
pro-eth-mint-ops-ui-lb-1614706639.ap-east-1.elb.amazonaws.com.

$ nslookup pro-eth-mint-ops-ui-lb-1614706639.ap-east-1.elb.amazonaws.com
** server can't find [...]: NXDOMAIN

$ curl -sk https://mint-ops.ethena.fi
# Connection refused — nothing listening

Additional: Vercel 404

dev-network.ethena.fi CNAMEs to cname.vercel-dns.com (generic Vercel CNAME) and returns a 404. If this domain isn't claimed in any Vercel project, someone could add it to their own deployment.

Impact Assessment

A subdomain takeover on mint-ops.ethena.fi would allow an attacker to:

• Phish internal team members — anyone with this URL bookmarked or in documentation would land on attacker-controlled infrastructure
• Steal cookies — if any cookies are scoped to .ethena.fi (parent domain), they're sent to the attacker automatically
• Issue valid TLS certificates — Let's Encrypt would happily issue a cert for mint-ops.ethena.fi via HTTP-01 challenge on the controlled server
• Intercept OAuth flows — if any redirect URIs match *.ethena.fi patterns

The practical exploitability depends on whether the AWS ELB name can be reclaimed. Classic ELBs had a known name-reuse vulnerability, though AWS has been tightening this. Regardless, the dangling DNS record should be removed.

Takeaways

Even well-funded DeFi protocols with serious security programs leave DNS hygiene gaps. The methodology is simple:

1. Enumerate — subfinder for passive discovery
2. Resolve — dnsx to find what's live and what's dead
3. Map CNAMEs — dig to trace the chain
4. Verify — nslookup/curl to confirm the target is truly dead

The whole process took about 10 minutes. The tools are free. The only hard part is understanding what you're looking at.

Tools Used

• subfinder — passive subdomain enumeration
• dnsx — fast DNS resolution and CNAME lookup
• httpx — HTTP probing with tech detection
• dig / nslookup — DNS verification