Merge pull request #129 from Hacking-the-Cloud/update_takeover_article

Fixed syntax/format for S3 subdomain takeover article.

content/aws/exploitation/orphaned_ cloudfront_or_dns_takeover_via_s3.md

@@ -1,9 +1,14 @@
 ---
 author: Houston Hopkins
-title: Simple Route53/Cloudfront/s3 subdomain takeover
-description: Techniques for taking over subdomains or hostnames that use Cloudfront and/or a DNS record to serve content from Amazone S3
+title: Simple Route53/Cloudfront/S3 Subdomain Takeover
+description: Techniques for taking over subdomains or hostnames that use Cloudfront and/or a DNS record to serve content from Amazon S3
 ---
 
+Research Example: [Patrik Hudak](https://0xpatrik.com/subdomain-takeover-basics/)  
+Link to Tool: [dwatch](https://github.com/houey/dwatch)  
+Link to Tool: [ctfr](https://github.com/UnaPibaGeek/ctfr)  
+Link to Tool: [Amass](https://github.com/OWASP/Amass)  
+
 Utilizing various enumeration techniques for recon and enumeration, an attacker can discover orphaned Cloudfront distributions and/or DNS Records that are attempting to serve content from an S3 bucket that no longer exists. There are numerous tools to do this, but I have been using dwatch combined with CTFR 
 
 Essentially you need a list of domains to check. Create a domain list using CTFR or amass or the like, and then utilize a tool like dwatch to test each host to look for a specific error page that contains the text "NoSuchBucket"
@@ -28,7 +33,7 @@ This alone can be enough to stop the bucket from being taken over by anyone else
 <h2> demo purposes only. </h2> 
 ```
 
-Root Causes of this issue are typically due to a hygiene realted issues where an s3 bucket was deleted while content was still being served by Cloudfront or by a DNS Record CNAME (Route53 or otherwise).  
+Root Causes of this issue are typically due to a hygiene realted issues where an S3 bucket was deleted while content was still being served by Cloudfront or by a DNS Record CNAME (Route53 or otherwise).  
 
 There are other nuanced conditions with Cloudfront, although rare, that can cause the similar takeover susceptibility.
 
@@ -38,12 +43,4 @@ Always create in this order **S3 -> Cloudfront -> DNS**
 
 Always Sunset/Delete in this order **DNS -> Cloudfront-> S3**
 
-Likewise, if you are testing, and something doesn't work, dont forget to clean up!
-
-
-
-* **Original Research**: [Patrik Hudak](https://0xpatrik.com/subdomain-takeover-basics/
-* **Link to Tool**: [GitHub](https://github.com/houey/dwatch)
-* **Link to Tool**: [GitHub](https://github.com/UnaPibaGeek/ctfr)
-* **Link to Tool**: [Github](https://github.com/OWASP/Amass)
-* **H/T**: [fng, ebelties, 0xpatrik, vysecurity, Amazon Cloudfront Service team]
+Likewise, if you are testing, and something doesn't work, dont forget to clean up!