Taken: The AWS Elastic IP Brute-Force Tool That Exposes Subdomain Takeover at Scale
Hook
An attacker can claim your company's subdomain for about $6 per day by simply restarting AWS instances until they win the Elastic IP lottery. This is how subdomain takeover went from manual reconnaissance to automated brute-force.
Context
Subdomain takeovers have plagued organizations since the early days of cloud computing. The vulnerability emerges when a company points a DNS record (like blog.company.com) to a cloud resource—an EC2 instance, a load balancer, or an S3 bucket—then deletes that resource without cleaning up the DNS entry. The subdomain becomes 'dangling,' still resolving to an IP or hostname that anyone can now claim. The security implications are severe: attackers controlling a subdomain can steal session cookies, bypass CORS policies, intercept OAuth flows, and send phishing emails from legitimate domains.
Traditionally, finding these vulnerabilities required manual enumeration: security researchers would compile lists of subdomains, check their DNS records, identify cloud providers through fingerprinting, and test whether those resources were claimable. Tools like subjack and SubOver automated the detection side but stopped short of actual exploitation. Taken takes a fundamentally different approach—instead of passively detecting vulnerable configurations, it actively cycles through AWS's Elastic IP address pool until it lands on an IP that matches a dangling DNS record. It transforms subdomain takeover from reconnaissance into a numbers game, treating AWS's IP allocation system as a brute-forceable resource.
Technical Insight
Taken's architecture consists of two Python scripts working in concert across multiple EC2 instances. The first component, subdomain_collector.py, builds the target database by harvesting subdomains from sources like certificate transparency logs or enumeration tools, then filters for AWS-hosted targets through reverse DNS lookups. It identifies candidates by checking if DNS records resolve to AWS IP ranges and storing them in a SQLite database.
The exploitation component runs across a fleet of EC2 instances—typically 10-20 t3a.nano instances spread across multiple AWS regions. Each instance executes a simple but effective loop:
import boto3
import socket
import time
def rotate_and_check(instance_id, region, target_ips):
ec2 = boto3.client('ec2', region_name=region)
while True:
# Restart instance to force new Elastic IP assignment
ec2.stop_instances(InstanceIds=[instance_id])
waiter = ec2.get_waiter('instance_stopped')
waiter.wait(InstanceIds=[instance_id])
ec2.start_instances(InstanceIds=[instance_id])
waiter = ec2.get_waiter('instance_running')
waiter.wait(InstanceIds=[instance_id])
# Check newly assigned IP against target list
response = ec2.describe_instances(InstanceIds=[instance_id])
current_ip = response['Reservations'][0]['Instances'][0]['PublicIpAddress']
if current_ip in target_ips:
send_alert(current_ip, find_matching_subdomain(current_ip))
return current_ip
time.sleep(60) # AWS API rate limiting
The genius—and danger—of this approach lies in understanding AWS's Elastic IP allocation mechanics. When an EC2 instance starts, AWS assigns it a public IP from the region's available pool. By forcing continuous restarts, Taken effectively brute-forces this allocation system, cycling through thousands of IPs daily. According to the repository documentation, 10 instances can perform approximately 14,400 IP rotations in 24 hours (assuming 6 rotations per instance per hour accounting for boot time and API limits).
The tool coordinates across regions to maximize coverage. AWS divides its IP space into regional pools, and companies often host infrastructure close to their primary markets. By running instances in us-east-1, us-west-2, and eu-west-1 simultaneously, attackers increase the probability that their rotated IPs will intersect with target infrastructure:
REGIONS = ['us-east-1', 'us-west-2', 'eu-west-1', 'ap-southeast-1']
INSTANCES_PER_REGION = 3
for region in REGIONS:
for i in range(INSTANCES_PER_REGION):
launch_worker(region=region,
target_list=subdomain_db,
instance_type='t3a.nano')
When a match occurs, the tool sends an email notification and halts that particular instance. The attacker then manually SSHs into the machine and deploys a proof-of-concept web server. This is where Taken shows its age and lack of sophistication—there's no automated PoC deployment, no SSL certificate generation via Let's Encrypt, no integration with exploitation frameworks. It's a pure reconnaissance tool that identifies the opportunity but leaves the weaponization to the operator.
The economic model is surprisingly efficient for attackers. A t3a.nano instance costs approximately $0.0047/hour or $3.40/month when running continuously. With 10 instances across regions, monthly infrastructure costs hover around $34, though the constant restart cycles effectively double this to about $60-70 when accounting for fractional hour billing. For bug bounty hunters, this positions Taken as a 'set it and forget it' passive income tool—invest $70 monthly and wait for findings that might pay $500-5000 per valid subdomain takeover report.
Gotcha
The brute-force nature of Taken creates significant operational and ethical problems. First, the success rate is abysmal by design—you're essentially buying lottery tickets hoping your randomly assigned IP matches one of potentially thousands of target IPs. The repository claims three successful takeovers in 24 hours, but this doesn't account for the size of the target list or whether these were from a curated high-probability dataset. Running blind against a general subdomain enumeration list would likely yield nothing for days or weeks, making the cost-per-finding prohibitively expensive compared to passive detection tools.
More critically, this technique is extraordinarily noisy and potentially illegal without explicit authorization. Each instance restart generates CloudTrail logs, triggering alerts in any competent security operations center. AWS may flag the account for abuse given the unusual pattern of constant restarts—behavior that mimics cryptomining or resource exhaustion attacks. From a legal perspective, actively claiming someone else's subdomain crosses from reconnaissance into unauthorized access in most jurisdictions, even if the DNS record was misconfigured. Bug bounty programs typically prohibit infrastructure attacks against third-party providers like AWS, making Taken unusable for legitimate security research in most scenarios. The tool also only addresses AWS Elastic IPs—it's completely blind to Azure, GCP, subdomain takeovers via GitHub Pages, Heroku, Netlify, or the dozens of other services where this vulnerability commonly appears.
Verdict
Use if: You're conducting an authorized red team engagement where the client specifically wants to understand AWS-based subdomain takeover risks and has provided written permission for aggressive infrastructure testing. This tool demonstrates a real attack vector that passive scanners miss—the possibility of patient attackers cycling through IP pools over weeks or months. It's valuable for security training to illustrate why DNS hygiene matters and why dangling records should be treated as critical vulnerabilities, not housekeeping tasks. Skip if: You're doing bug bounty work (the legal risks and program rule violations aren't worth it), you need reliable subdomain takeover detection (subjack or nuclei will find vulnerabilities in minutes instead of days), you're working with limited budgets (passive tools are free and more effective), or you care about ethical security research (this technique actively claims resources rather than just detecting misconfigurations). For 95% of security practitioners, the passive detection alternatives provide better ROI with none of the legal or technical baggage.