non-selectable line numbers on code fences

content/notes/finding-candidates-subdomain-takeovers/index.md

@@ -45,19 +45,19 @@ Conveniently, [Rapid7](https://www.rapid7.com/) publishes a monthly list for us
 
 One of their free monthly datasets is called [Forward DNS](https://opendata.rapid7.com/sonar.fdns_v2/), where you'll find `.json` files named `xxxx-fdns_cname.json.gz`. Within the [`subtake`](https://github.com/jakejarvis/subtake) repository, there's an automated script named [`sonar.sh`](https://github.com/jakejarvis/subtake/blob/master/sonar.sh), which downloads the dataset for you and outputs a simple text file of CNAMEs pointed to any of the services listed above. Once you've [cloned the `subtake` repository](https://github.com/jakejarvis/subtake) and grabbed the timestamp part of the filename (the string that precedes `-fdns_cname.json.gz`), usage of the script is as follows:
 
-```bash
+```bash {linenos=false}
 ./sonar.sh 2019-03-30-1553989414 sonar_output.txt
 ```
 
 This new text file contains *both active and abandoned* subdomains pointing to any of the services listed above -- we still need to narrow it down to the takeover candidates by attempting to actually resolve each of them, which is where `subtake` comes into play. To install `subtake`, make sure [Go is installed first](https://golang.org/doc/install#install) and run the following:
 
-```bash
+```bash {linenos=false}
 go get github.com/jakejarvis/subtake
 ```
 
 For a detailed description of the different options you can play around with, see the [full readme on GitHub](https://github.com/jakejarvis/subtake#usage) -- but here's a simple example command that uses 50 threads to take the CNAMEs listed in `sonar_output.txt` and outputs potentially vulnerable subdomains to `vulnerable.txt`.
 
-```bash
+```bash {linenos=false}
 subtake -f sonar_output.txt -c fingerprints.json -t 50 -ssl -a -o vulnerable.txt
 ```
 
@@ -65,7 +65,7 @@ This could take quite a while -- up to a day, depending on your CPU, memory, and
 
 I also have a collection of root domains of companies offering bounties through [HackerOne](https://hackerone.com/directory/) or [Bugcrowd](https://bugcrowd.com/programs) at a [different GitHub repository](https://github.com/jakejarvis/bounty-domains/). Using the [`grep`-friendly text file](https://github.com/jakejarvis/bounty-domains/blob/master/grep.txt), it's easy to use [`grep`](http://man7.org/linux/man-pages/man1/grep.1.html) to narrow down your `vulnerable.txt` list even more:
 
-```bash
+```bash {linenos=false}
 grep -f grep.txt vulnerable.txt
 ```
 
@@ -75,7 +75,6 @@ In my view, takeovers are a fantastic way to begin a side hustle in bug bounties
 
 Since you have this luxury of time, it becomes ***extremely important*** that you let your adrenaline subside and follow [responsible disclosure](https://www.bugcrowd.com/resource/what-is-responsible-disclosure/) guidelines -- especially in the creation of a "proof of concept" file with your username at an obscure location, **not** at `index.html`. I won't go over the details of writing a report because [Patrik Hudak](https://twitter.com/0xpatrik) wrote another [great post about it here](https://0xpatrik.com/takeover-proofs/). This is an example of one of my own reports (company name censored because it has not been publicly disclosed) on [Bugcrowd](https://bugcrowd.com/programs):
 
-
 > I have found three subdomains of ********.com vulnerable to takeovers via unclaimed endpoints at [Azure's Traffic Manager](https://azure.microsoft.com/en-us/services/traffic-manager/). I have claimed these endpoints and redirected them to a blank page to prevent a bad actor from doing so in the meantime, and hosted a POC file at obscure URLs. These are the following domains I discovered and the outdated endpoints on Azure to which they point:
 >
 > xxxx.********.com --> aaa.trafficmanager.net
@@ -96,7 +95,6 @@ Since you have this luxury of time, it becomes ***extremely important*** that yo
 >
 > Please let me know when you've received this report and I'll delete the endpoints from my personal Azure account, so you can either reclaim them or remove the subdomains entirely from your DNS records. Thanks!
 
-
 I removed the company's name because an important part of responsible *disclosure* is the *disclosure*, or lack thereof. Until the company explicitly gives permission to publicly disclose the vulnerability after patching it -- and there are built-in features on both HackerOne and Bugcrowd to request this -- it's **not okay** to talk about it publicly.
 
 The `poc-d4ca9e8ceb.html` proof-of-concept file contained this single, hidden line: