How Taken Weaponizes AWS IP Rotation to Automate Subdomain Takeover at Scale
Hook
For $60 a month, you can cycle through 14,400 AWS IP addresses daily, waiting for one to match a forgotten DNS record pointing to a decommissioned server. That’s the economics of automated subdomain takeover.
Context
Subdomain takeover vulnerabilities occur when a DNS record points to a cloud resource that no longer exists—typically a terminated EC2 instance or deleted S3 bucket. If an attacker can claim that IP address or resource identifier, they control what appears when users visit that subdomain. The security implications are severe: stealing cookies with domain attributes set broadly, bypassing CORS policies, hijacking OAuth redirects, circumventing CSP restrictions, enabling clickjacking, and even spoofing emails via SPF records.
Traditional subdomain takeover tools like subjack and SubOver excel at detection—they fingerprint vulnerable subdomains by checking DNS records against known cloud provider patterns. But they stop at identification. Taken takes a fundamentally different approach: it doesn’t just find dangling AWS subdomains, it actively acquires them through brute-force IP rotation. Created by Vaibhav Agrawal in 2020, this bash-based automation tool exploits a quirk of AWS infrastructure: every time you restart an EC2 instance, it receives a new public IP from AWS’s pool. By orchestrating multiple instances to restart continuously, Taken creates a probabilistic machine that eventually cycles into an IP address that a target subdomain still references.
Technical Insight
Taken’s architecture centers on bash orchestration across a fleet of micro EC2 instances. The workflow begins with reconnaissance: the subdomain collection script leverages subfinder and Sublist3r to enumerate subdomains for target domains stored in an alldomains file. It then performs reverse DNS lookups to filter only those subdomains resolving to AWS IP ranges, creating a target list in subdomain:IP format.
The core innovation lies in the IP rotation loop. You deploy 5-10 t3a.nano instances (AWS’s cheapest compute tier at ~$3.80/month each) across multiple regions, then use AWS API credentials to programmatically restart them every minute. Each restart forces AWS to deallocate the current public IP and assign a new one from the regional IP pool. The takeover script checks if the newly assigned IP matches any in the target subdomain list. When a match occurs, the script appears to whitelist that IP to prevent rotation loss and triggers an email notification via SSMTP.
The mathematics of this approach reveal its probabilistic nature. With instance restarts every minute, a single t3a.nano cycles through approximately 1,440 IP addresses per day (60 minutes × 24 hours). Deploy 10 instances and you’re sampling 14,400 IPs daily from AWS’s IP space. AWS’s public IP pools are finite per region—while exact sizes aren’t published, the attack surface grows as you add regions. Companies often leave DNS records pointing to decommissioned infrastructure in the same regions where they actively operate, making multi-region deployment strategic rather than random.
The tooling requires a t2.medium “attack machine” (free tier eligible) as the orchestration hub. You run the subdomain collection script in one GNU screen session and launch separate takeover scripts for each target region in additional screen sessions. This screen-based approach ensures processes survive SSH disconnections during long-running campaigns. The multi-region strategy targets the reality that if a company is US-based, they likely have historical infrastructure in us-east-1, us-west-2, and perhaps eu-west-1 for European operations.
Once you successfully claim an IP matching a target subdomain, the manual POC deployment involves SSH-ing to that instance and hosting proof-of-concept content. The README suggests creating a simple HTML file and starting a python server to make it accessible when someone visits the taken-over subdomain.
The setup requires AWS API credentials exported as environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY). The security model assumes you’re operating within your own AWS account with instances you control—there’s no exploitation of AWS itself, only leveraging the IP recycling behavior that’s inherent to elastic IP architecture.
Gotcha
Taken’s probabilistic model is simultaneously its strength and fatal flaw. Success is never guaranteed—you’re essentially playing a lottery where your odds improve with ticket volume (instances running) but never reach certainty. If AWS’s regional IP pool contains millions of addresses and your target subdomain points to one of them, the time-to-takeover could range from hours to never. The README claims three takeovers within 24 hours when targeting public bug bounty programs, but that success rate isn’t reproducible without knowing the size of the target list and the staleness of those DNS records.
Cost optimization becomes critical at scale. While $60/month for 10 t3a.nano instances sounds reasonable, AWS charges for data transfer and API calls that could add marginal costs. More importantly, aggressive automation against production infrastructure in bug bounty programs risks violating program terms. Many explicitly prohibit automated scanning or actions that could impact availability—repeatedly claiming IPs could theoretically interfere with legitimate AWS operations, though the practical risk is low.
The manual setup burden is significant. You must manually provision instances across regions, configure SSMTP with SMTP credentials (often requiring app-specific passwords for Gmail), install subfinder and Sublist3r with their respective dependencies, and manage screen sessions. The implementation details suggest this requires substantial operational overhead to maintain.
Ethically and legally, automated subdomain takeover occupies ambiguous territory. While security researchers use these techniques legitimately in bug bounty contexts, the same methodology could constitute unauthorized access if applied outside approved scopes.
Verdict
Use Taken if you’re an experienced bug bounty hunter running systematic subdomain takeover campaigns across dozens of programs where AWS-hosted infrastructure is prevalent, you can justify the $60-100/month EC2 spend as a business expense, and you’re comfortable with probabilistic outcomes measured in days rather than hours. The tool excels when you need coverage at scale rather than surgical precision—think bulk screening of hundreds of dangling subdomains where even a 2-3% hit rate justifies the cost. Skip it if you’re investigating a specific high-value target where manual verification makes more sense, if you lack the AWS operational knowledge to troubleshoot instance lifecycle issues, if your bug bounty budget can’t absorb the monthly cloud costs with uncertain ROI, or if you’re uncomfortable with the aggressive automation posture this approach requires. For most security researchers, detection-focused tools like subjack provide better effort-to-value ratios—only adopt Taken when you’ve already exhausted conventional methods and want to industrialize the IP acquisition phase.
