Update domain-subdomain-takeover.md

pentesting-web/domain-subdomain-takeover.md

@@ -2,7 +2,7 @@
 
 ## Domain takeover
 
-If you discover some domain \(domain.tld\) that is **being used by some service inside the scope** but the **company** has l**o**st the **ownership** of it, you can try to **register** it \(if cheap enough\) and let know the company. If this domain is receiving some **sensitive information** like a sessions cookie via **GET** parameter or in the **Referral** header, this is for sure a **vulnerability**.
+If you discover some domain \(domain.tld\) that is **being used by some service inside the scope** but the **company** has l**o**st the **ownership** of it, you can try to **register** it \(if cheap enough\) and let know the company. If this domain is receiving some **sensitive information** like a sessions cookie via **GET** parameter or in the **Referer** header, this is for sure a **vulnerability**.
 
 ### Subdomain takeover
 
@@ -105,9 +105,9 @@ One of the problems in subdomain takeover using NS record is that the source dom
 
 1. Since there are two nameservers, one is randomly chosen. This means the probability of querying nameserver controlled by an attacker is 50%.
 2. If user's DNS resolver chooses _ns.nonvulnerable.com_ \(legitimate nameserver\), the correct result is returned and likely being cached somewhere between 6 and 24 hours.
-3. If user's DNS resolver chooses _ns.vulnerable.com_ \(nameserver owned by an attacker\), an attacker might provide a false result which will also be cached. Since an attacker is in control of nameserver, she can set TTL for this particular result to be for example one week.
+3. If user's DNS resolver chooses _ns.vulnerable.com_ \(nameserver owned by an attacker\), an attacker might provide a fake result which will also be cached. Since an attacker is in control of nameserver, she can set TTL for this particular result to be for example one week.
 
-The process above is repeated every time the cache entry expires. When an attacker chooses to use TTL with high value, the false result will stay in DNS cache for that period. During this time, all requests to _sub.example.com_ will use false DNS result cached by an attacker. This idea is even amplified when public DNS resolvers \(e.g., Google DNS\) are used. In this case, public resolvers are likely to cache the false results which means that all users using the same DNS resolver will obtain false results until the cache is revoked.
+The process above is repeated every time the cache entry expires. When an attacker chooses to use TTL with high value, the fake result will stay in DNS cache for that period. During this time, all requests to _sub.example.com_ will use fake DNS result cached by an attacker. This idea is even amplified when public DNS resolvers \(e.g., Google DNS\) are used. In this case, public resolvers are likely to cache the fake results which means that all users using the same DNS resolver will obtain fake results until the cache is revoked.
 
 In addition to control over the source domain name, control over all higher-level domains of source domain name is gained as well. That is because owning a canonical domain name of NS record means owning the full DNS zone of the source domain name.
 
@@ -119,7 +119,7 @@ Matthew also [demonstrated](https://thehackerblog.com/the-io-error-taking-contro
 
 The mitigation strategies for domain names already vulnerable to subdomain takeover are rather straightforward:
 
-* **Remove the affected DNS record** — The simplest solution is to remove the affected record from the DNS zone. This step is usually used if the organization determines that the affected source domain name is no longer needed.
+* **Remove the affected DNS record** — The simplest solution is to remove the affected record from the DNS zone. This step is usually used if the organization concludes that the affected source domain name is no longer needed.
 * **Claim the domain name** — This means registering the resource in particular cloud provider or a case of a regular Internet domain, repurchasing the expired domain.
 
 To prevent subdomain takeover in the future, organizations should change the process of creating and destructing resources in their infrastructure. In case of resource creation, the DNS record creation has to be the _last step_ of this process. This condition prevents DNS record to be pointing to a non-existing domain at any point in time. For resource destruction, the opposite holds: DNS record needs to be removed as the _first step_ in this process. Tools such as [aquatone](https://github.com/michenriksen/aquatone) include checks for subdomain takeover. The checks should be periodically performed by a security team of an organization to verify that there are no vulnerable domains. Processes for central collection of exposed domain names are often not efficient inside organizations \(due to global teams, etc.\) and external monitoring is usually the best way to go.