Author: Karl

Introduction

Welcome back to the second installment of our exploration into Certspotter and the world of passive reconnaissance. In Part 1, we laid the groundwork for understanding the significance of Certspotter as a vital tool in monitoring certificate transparency logs. We delved into the nuances of passive reconnaissance, highlighting the importance of discreet operations in gathering intelligence without alerting targets.

Now, in Part 2, we’re ready to dive even deeper. Building upon the foundation established in Part 1, we’ll explore advanced techniques for leveraging Certspotter’s capabilities to their fullest potential. Our focus will be on enriching the data obtained from Certspotter and enhancing our reconnaissance efforts through the integration of additional tools and methodologies.

Join me as I uncover the untapped potential of Certspotter and embark on a journey to uncover valuable insights that will inform and empower your hacking strategies. Let’s dive in and elevate our reconnaissance game to new heights.

Data Enrichment

So, you’ve already gathered a wealth of information about your target. But let’s take it a step further.

Here’s what you want to know:

• What’s running on the new subdomain?
• Any interesting paths?
• Open ports?
• Can we capture a screenshot?
• Are there any potential vulnerabilities?
• Perhaps you have a custom target, like specifically testing for WordPress.

Now, there might be a tool out there that handles all these tasks, but I haven’t found it yet. (Feel free to shoot me a message on Signal if you know one). Instead, I’ve decided to build a tool together with you, right here, right now, leveraging ProjectDiscovery’s Tools, which are awesome open-source projects written in one of my favorite languages: Go.

However, as we transition from passive to active reconnaissance, I must reiterate the importance of reading my disclaimer.

Web Technology:

For this task, we’ll use a tool called Webanalyze.

# Installation
go install -v github.com/rverton/webanalyze/cmd/webanalyze@latest

# Update
$HOME/go/bin/webanalyze -update

Now, a quick note: I’m not authorized to recon sandbox.google.com. If, by chance, any of my tools cause a denial of service state on the endpoint, I might be held liable for damages.

To demonstrate, I whitelisted my IP and scanned my own website:

$HOME/go/bin/webanalyze -host exploit.to -crawl 2
 :: webanalyze        : v0.3.9
 :: workers           : 4
 :: technologies      : technologies.json
 :: crawl count       : 2
 :: search subdomains : true
 :: follow redirects  : false

http://exploit.to (0.6s):
    HSTS,  (Security)
    HTTP/3,  (Miscellaneous)
    Cloudflare,  (CDN)
    Astro, 4.5.2 (Static site generator, JavaScript frameworks)

For further consumption I suggest using -output json and storing it locally or sending it to your central system.

Screenshot

For this task, we’ll utilize playwright. While some might argue that this is overkill, I have some future plans in mind. You can learn more about playwright here.

npm init playwright@latest

Simply respond with “yes” to all the prompts, as having a positive attitude is always beneficial.

Below is a script that captures a full-page screenshot and lists all the network calls made by a loaded page:

const { chromium } = require("playwright");

(async () => {
  // Launch browser
  const browser = await chromium.launch();

  // Create a new page
  const page = await browser.newPage();

  // Enable request interception
  await page.route("**", (route) => {
    console.log(route.request().url());
    route.continue();
  });

  // Navigate to the desired page
  await page.goto("https://exploit.to");

  // Take a full-page screenshot
  await page.screenshot({ path: "exploit.png", fullPage: true });

  // Close the browser
  await browser.close();
})();

Here’s how you can run the script and check its output:

sudo node screenshot.js

https://exploit.to/
https://exploit.to/_astro/styles.DS6QQjAg.css
https://exploit.to/_astro/hoisted.DfX8MIxs.js
https://exploit.to/_astro/page.BZ5QGxwt.js
https://exploit.to/_astro/ViewTransitions.astro_astro_type_script_index_0_lang.D0ayWLBG.js
https://exploit.to/_astro/index.Vl7qCdEu.js
https://exploit.to/_astro/CryptoBackground.c9l8WxZ_.js
https://exploit.to/_astro/client.B60e5CTm.js
https://exploit.to/cdn-cgi/challenge-platform/scripts/jsd/main.js
https://exploit.to/_astro/index.LHP-L4Pl.js
https://exploit.to/_astro/index.C3GvvkrT.js
https://exploit.to/_astro/jsx-runtime.BoiYzbTN.js
https://exploit.to/_astro/utils.xgzLAuTe.js

Open Ports

Understanding the open ports on a target system can provide valuable insights into its network architecture and potential vulnerabilities. To accomplish this, we’ll conduct a quick scan using nmap, a powerful network scanning tool.

sudo nmap -sS -Pn -T4 exploit.to

This command initiates a SYN scan (-sS) without host discovery (-Pn) at an aggressive timing level (-T4) against the target exploit.to.

Here’s a breakdown of the scan results:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-25 15:14 CET
Nmap scan report for exploit.to (IP)
Host is up (0.10s latency).
Other addresses for exploit.to (not scanned): IP
Not shown: 996 filtered tcp ports (no-response)
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
8080/tcp open  http-proxy
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 8.17 seconds

The scan reveals the following open ports:

• Port 80/tcp: Open for HTTP.
• Port 443/tcp: Open for HTTPS.
• Port 8080/tcp: Open for HTTP proxy.
• Port 8443/tcp: Open for alternate HTTPS.

Subdomains

Exploring subdomains can uncover hidden entry points and potential vulnerabilities within a target’s infrastructure. Let’s leverage Subfinder for passive subdomain enumeration and HTTPX for validation.

go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

You can easily pipe the output of subfinder to httpx for further analysis:

$HOME/go/bin/subfinder -d sandbox.google.com | $HOME/go/bin/httpx -status-code -title -tech-detect

Here’s a basic setup, but you can fine-tune these flags extensively. Additionally, I recommend integrating free API Keys to enhance subdomain discovery.

In our hypothetical Google case, here are some findings:

https://ecc-test.sandbox.google.com [200] [ECC-capable Certificate Success] [HTTP/3]
https://dry.sandbox.google.com [404] [Error 404 (Not Found)!!1] [HTTP/3]
https://during.sandbox.google.com [404] [Error 404 (Not Found)!!1] [HTTP/3]
https://earth.sandbox.google.com [404] [Error 404 (Not Found)!!1] [HTTP/3]
https://cert-test.sandbox.google.com [200] [Test Success] [HTTP/3]
https://dynamite-preprod.sandbox.google.com [302] [] [HSTS,HTTP/3]

The tech detection capabilities are surprisingly robust. In my earlier site example, the results were as follows:

https://exploit.to [200] [Karl Machleidt | Cyber Security Expert] [Astro:4.5.2,Cloudflare,HSTS,HTTP/3]

Paths

Now, let’s delve into fuzzing some paths. While tools like Gobuster can handle both subdomain enumeration and directory enumeration, I’d like to showcase some different tools for this task.

For the wordlist, we’ll use Daniel Miessler’s SecLists common.txt.

gobuster dir  --useragent "EXPLOIT.TO" --wordlist "common.txt" --url https://exploit.to

Here’s a breakdown of the Gobuster scan results:

===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     https://exploit.to
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                common.txt
[+] Negative Status codes:   404
[+] User Agent:              EXPLOIT.TO
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.git/index           (Status: 308) [Size: 0] [--> /.git/]
/.well-known/http-opportunistic (Status: 200) [Size: 21]
/404                  (Status: 200) [Size: 17047]
/about                (Status: 308) [Size: 0] [--> /about/]
/blog                 (Status: 308) [Size: 0] [--> /blog/]
/contact              (Status: 308) [Size: 0] [--> /contact/]
/disclaimer           (Status: 308) [Size: 0] [--> /disclaimer/]
/feed                 (Status: 301) [Size: 0] [--> https://exploit.to/rss.xml]
/index                (Status: 308) [Size: 0] [--> /]
/index.html           (Status: 308) [Size: 0] [--> /]
/robots.txt           (Status: 200) [Size: 57]
/rss                  (Status: 301) [Size: 0] [--> https://exploit.to/rss.xml]
/search               (Status: 308) [Size: 0] [--> /search/]
/tags                 (Status: 308) [Size: 0] [--> /tags/]
/tools                (Status: 308) [Size: 0] [--> /tools/]
Progress: 4727 / 4727 (100.00%)
===============================================================
Finished
===============================================================

These results provide insights into various paths on the target site, facilitating potential avenues for further exploration and potential vulnerabilities.

Vulnerabilities

Vulnerability scanners are notorious for their loud presence, and we have several options at our disposal:

• OpenVAS
• OWASP ZAP
• Nuclei

For this demonstration, I’ll opt for Nuclei, which simplifies custom discovery tasks significantly.

To install Nuclei, execute the following command:

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Using Nuclei without specifying templates to use can generate excessive traffic. Here’s an example command specifying templates:

$HOME/go/bin/nuclei -target exploit.to -t http/cves/ -t ssl

Running Nuclei with all available templates can uncover a plethora of issues. However, be cautious, as this scan can be aggressive. Here’s an example scan of my website. Note that running such a scan on unauthorized targets is not recommended:

[nameserver-fingerprint] [dns] [info] exploit.to [jonah.ns.cloudflare.com.,uma.ns.cloudflare.com.]
[caa-fingerprint] [dns] [info] exploit.to
[dmarc-detect] [dns] [info] _dmarc.exploit.to ["v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected];"]
[mx-fingerprint] [dns] [info] exploit.to [54 route1.mx.cloudflare.net.,84 route2.mx.cloudflare.net.,98 route3.mx.cloudflare.net.]
[txt-fingerprint] [dns] [info] exploit.to ["v=spf1 include:_spf.mx.cloudflare.net ~all"]
[spf-record-detect] [dns] [info] exploit.to [v=spf1 include:_spf.mx.cloudflare.net ~all"]
[dns-waf-detect:cloudflare] [dns] [info] exploit.to
[INF] Using Interactsh Server: oast.fun
[addeventlistener-detect] [http] [info] https://exploit.to
[xss-deprecated-header] [http] [info] https://exploit.to [1; mode=block]
[metatag-cms] [http] [info] https://exploit.to [Astro v4.5.2]
[tech-detect:cloudflare] [http] [info] https://exploit.to
[http-missing-security-headers:content-security-policy] [http] [info] https://exploit.to
[http-missing-security-headers:permissions-policy] [http] [info] https://exploit.to
[http-missing-security-headers:x-permitted-cross-domain-policies] [http] [info] https://exploit.to
[http-missing-security-headers:clear-site-data] [http] [info] https://exploit.to
[http-missing-security-headers:cross-origin-embedder-policy] [http] [info] https://exploit.to
[http-missing-security-headers:cross-origin-opener-policy] [http] [info] https://exploit.to
[http-missing-security-headers:cross-origin-resource-policy] [http] [info] https://exploit.to
[robots-txt-endpoint] [http] [info] https://exploit.to/robots.txt
[waf-detect:cloudflare] [http] [info] https://exploit.to/
[ssl-issuer] [ssl] [info] exploit.to:443 [Google Trust Services LLC]
[ssl-dns-names] [ssl] [info] exploit.to:443 [exploit.to]

Let’s break down some of the identified vulnerabilities from the Nuclei scan results:

1. nameserver-fingerprint [dns]: This vulnerability detection identifies the nameservers associated with the domain exploit.to, revealing that it is using Cloudflare’s nameservers (jonah.ns.cloudflare.com and uma.ns.cloudflare.com). While not necessarily a vulnerability, this information can be useful for reconnaissance purposes.
2. caa-fingerprint [dns]: This indicates the absence of CAA (Certificate Authority Authorization) records for the domain exploit.to. CAA records specify which certificate authorities are allowed to issue certificates for a domain. Lack of CAA records might imply less control over certificate issuance, potentially leaving the domain vulnerable to unauthorized certificate issuance.
3. dmarc-detect [dns]: This detection reveals the DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy for the domain _dmarc.exploit.to. The policy specifies how a receiving mail server should handle emails that fail SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) checks. In this case, the policy is set to “reject,” indicating strict handling of failed authentication, which is generally considered good practice.
4. mx-fingerprint [dns]: This vulnerability detection identifies the mail servers (MX records) associated with the domain exploit.to, which are provided by Cloudflare. While not necessarily a vulnerability, this information can be useful for understanding the email infrastructure associated with the domain.
5. txt-fingerprint [dns]: This reveals the SPF (Sender Policy Framework) record for the domain exploit.to, specifying which servers are allowed to send emails on behalf of the domain. The record indicates that emails should be sent only from servers included in the _spf.mx.cloudflare.net include mechanism.
6. waf-detect:cloudflare [http]: This detection indicates the presence of a WAF (Web Application Firewall) provided by Cloudflare for the domain exploit.to. WAFs help protect web applications from common security threats such as SQL injection, cross-site scripting (XSS), and DDoS attacks.
7. ssl-issuer [ssl]: This reveals information about the SSL certificate issuer for the domain exploit.to, which is Google Trust Services LLC. SSL certificates issued by reputable authorities help establish secure HTTPS connections, ensuring data transmitted between the user’s browser and the web server remains encrypted and secure.

These are just a few examples of the vulnerabilities and configurations identified in the Nuclei scan results. Each of these findings provides valuable insights into potential security risks and areas for improvement in the domain’s infrastructure and configuration.

Custom

Now, let’s illustrate a simple example:

$HOME/go/bin/nuclei -target exploit.to -t http/honeypot/elasticpot-honeypot-detect.yaml

Imagine you’re interested in scanning for Elastipot, Elasticsearch honeypots. Identifying these honeypots beforehand can be crucial before launching any new zero-day attack on open Elasticsearch instances. While creating custom templates for such detections isn’t overly complicated, it allows you to tailor detection scripts to your specific needs. Alternatively, you can employ Gobuster, as mentioned earlier, to test for specific paths.

Recon Data

We’ve successfully gathered all the desired data:

•  Identification of services running on new subdomains.
•  Open ports analysis.
•  Screenshot capture.
•  Discovery of interesting paths.
•  Identification of possible vulnerabilities.
•  Custom targeting, such as explicit testing for WordPress.

We now know that our target is developing a new project, the technolgies used, possible vulnerabilities, interesting paths, have a screenshot and more.

Summary

We explored various reconnaissance techniques, from subdomain enumeration and directory scanning to vulnerability assessments and customized detections. Leveraging tools like Certspotter, Gobuster, Nuclei, and others, we gained profound insights into our target’s infrastructure and potential security vulnerabilities.

Our adventure began with an introduction to Certspotter, the pioneer in certificate transparency log monitoring. We dissected the significance of passive reconnaissance, emphasizing its discreet nature compared to active methods. With Certspotter, we learned how to continuously monitor for new subdomains and certificate registrations, all at minimal cost.

From envisioning scenarios of seizing control over freshly set up WordPress sites to stealthily infiltrating default credentials in Grafana or Jenkins installations, the possibilities for mischief are boundless. Armed with our newfound knowledge and toolkit, the next logical step involves automating these processes and integrating them into a centralized system for ongoing monitoring and analysis.

I am working on a Part 3. In the next part I want to combine all the tools to one final script that should be triggered whenever certspotter finds a new certificate:

• run dnsx
• run subfinder and httpx if wildcard else run httpx
• use playwright for screenshot and network traffic
• port scan
• maybe use httpx for path ? Otherwise gobuster Should also run alone based on domain, wildcard or subdomain input.

I want the output to be one final JSON I can then render on my website.

Introduction

Ever found yourself deep in the abyss of the internet, wishing you could uncover more than what’s on the surface? If so, Google Hacking, also known as Google Dorking, might just be your next favorite hobby. This amusing and surprisingly potent skill will turn you into an internet sleuth, uncovering secrets like a digital Sherlock Holmes. By the end of this article, you’ll be ready to create your own Google dorks and impress (or mildly concern) your friends with your newfound abilities.

If you’re interested in OSINT in general you can also check out my other articles:

• OSINT – Dorking with Brave Search
• Tool supported OSINT with Spiderfoot

What is Google Hacking?

Google Hacking , whcih is also called Google Dorking, is the playful art of using Google’s search engine to uncover sensitive information that wasn’t meant for public eyes. From personal data and financial info to website security flaws, Google Hacking can reveal it all. But don’t panic—it’s perfectly legal as long as you don’t misuse the info you stumble upon.

To break it down a bit, Google Hacking isn’t some kind of sorcery. It’s about finding anything that’s been indexed by Google or other major search engines. With the right search queries, you can dig up info that’s not ranking high on Google—often the kind of stuff that wasn’t meant to be easily found. So go ahead, have fun, and happy Googling (responsibly)!

Why the Term “Dorking”?

“Dork” in this context refers to a set of search parameters that expose unprotected information. Think of it as a key that unlocks hidden doors on the internet. The term “dorking” might sound silly, but the results can be pretty serious.

Tools of the Trade

Before we dive into the nitty-gritty, let’s talk about the essential tools and resources you’ll need:

1. Google Advanced Search Operators: These are special commands you can use in Google’s search bar to filter results more precisely. You can find a comprehensive list of these operators on Ahrefs’ blog.
2. Google Hacking Database (GHDB): A treasure trove of pre-made Google dorks. Check out the database on Exploit-DB to see what others have discovered.
3. Alternative Search Engines: Bing, DuckDuckGo, and Startpage also offer advanced search capabilities. Explore their documentation on Bing (and this), DuckDuckGo, and Startpage.
4. OSINT Tools: Tools like Pentest-Tools and IntelTechniques can enhance your search capabilities.

Pro tip: You can use Dorks from Exploit-DB to play around with them and create new dorks focued on your target or niche.

The Basics of Google Dorking

I will focus on Google here as it is the biggest search engine and will usually give you some solid results. Let’s start with some simple Google search operators:

1. site: – Restrict results to a specific website.
   • Example: site:example.com
2. filetype: – Search for specific file types.
   • Example: filetype:pdf
3. inurl: – Find URLs containing specific text.
   • Example: inurl:login
4. intitle: – Search for page titles containing specific text.
   • Example: intitle:index.of

Combining these operators can yield powerful results. For instance, to find login pages on example.com, you could use: site:example.com inurl:login

Let’s do another example searching a webiste for a contact email address (or to send them phishing mails (pls don’t)): "@cancom.de" site:"cancom.de"

Useful dorks to get started

Now for some fun! Here are a few beginner-friendly dorks, please feel free to copy and modify them to your liking:

1. Finding Open Directories:
   • intitle:"index of" "parent directory"
2. Discovering Public Cameras:
   • intitle:"Live View / - AXIS"
3. Uncovering Interesting PDFs:
   • filetype:pdf "confidential"
4. Locating Forgotten Passwords:
   • filetype:log inurl:"password"

Creating Your Own Dorks

Creating your own Google dorks is like cooking a new dish—start with the basics and experiment. Here’s a step-by-step guide:

1. Identify Your Target: Decide what type of information you’re seeking. Is it emails, passwords, or hidden directories?
2. Choose the Right Operators: Based on your target, select appropriate search operators.
   • Example: To find Excel files with passwords, you might use filetype:xls inurl:password.
3. Test and Refine: Enter your dork into Google and see what comes up. Refine your search terms to get more relevant results.
4. Document Your Findings: Keep a record of effective dorks for future reference. You never know when you might need them again!

You can combine many operators to refine your results.

Final Thoughts

Hooray! You’ve officially unlocked the secrets of Google Dorking. Get ready to dive deeper in the next part, where I’ll dish out more details and examples about other search engines and why they’re worth your time too. But before we move on, here are a few ways to flex your new skills:

• Become a Digital Bounty Hunter: Track down elusive individuals like a pro (In the U.S. you can check your states State Trooper website fpr active bounties).
• Debt Detective: Find those who owe you money faster than a speeding algorithm.
• Hack the Planet: Discover websites with vulnerable software
• Doxing – Beyond the usual “it’s illegal” disclaimer, doxing can irreversibly ruin someone’s life. Trust me, no matter how much you dislike someone, you do not want to go down this path.
• Find pirated Software

Stay tuned, because your Google Dorking journey is just getting started!