Recently a new project was released by Praetorian. Praetorian is open-sourcing the offensive tools their red team actually uses on engagements. They call it 12 Caesars and their team is planning to release one tool a week for twelve weeks. Every tool is written in Go and ships as a single binary with zero external dependencies.
Each tool is assigned a Caesar name and a blog post, where you can learn more about these tools.
We’ll look at four of these tools, including the basic ones, to make this article suitable for everyone. Before we proceed, it’s important to remind you that you can only test systems you own or have explicit written authorization to test. We will use our lab for it.
Titus
Our first tool is Titus. Titus finds credentials, API keys, and tokens in source code, files, git history, container images, and more. The tool has 487 detection rules covering AWS, GCP, Azure, GitHub, Slack, databases and hundreds of other services. Similar to TruffleHog, it can validate credentials as it finds them by calling the provider APIs.
It’s also available as a Burp Suite extension and a Chrome extension.
kali > curl -sL -o titus https://github.com/praetorian-inc/titus/releases/latest/download/titus-linux-amd64
kali > chmod 777 titus
kali > ./titus --help
Let’s start by pointing it at test keys released by Truffle Security.
It found all the keys in the repo. Companies often publish their secrets by accident. Some live in the repositories for years, so it’s good to do regular checks to prevent unnecessary leakage.
Nerva
Nerva is a fingerprinter supporting 170 protocols across TCP, UDP, and SCTP, plus dozens of HTTP technology fingerprinters. You can feed it with open ports from naabu, nmap or other tools and it’ll tell you what’s actually running with its version.
kali > curl -sL -o nerva.tar.gz https://github.com/praetorian-inc/nerva/releases/download/v1.70.3/nerva_1.70.3_linux_amd64.tar.gz
kali > tar --no-same-owner -xzf nerva.tar.gz
kali > chmod 777 nerva
kali > ./nerva --help
Now let’s use our Ubuntu to show a basic test.
kali > ./nerva -t 192.168.131.9:22,11434
It will be way more useful when you work with big lists of corporate assets during a pentest.
Brutus
Brutus is a modern Hydra alternative. It supports more than 40 protocols including SSH, RDP, MySQL, PostgreSQL and a lot more. Brutus was built to work with Nerva or naabu output.
kali > curl -sL -o brutus.tar.gz https://github.com/praetorian-inc/brutus/releases/latest/download/brutus-linux-amd64.tar.gz
kali > tar --no-same-owner -xzf brutus.tar.gz
kali > chmod 777 brutus
kali > ./brutus --help
Each command has its own help menu to make it easy to work with.
kali > ./brutus creds --help
Now once again lets use our Ubuntu to spay passwords.
kali > ./brutus creds --target 127.0.0.1:22 --protocol ssh “admin:admin”
It was easy. As mentioned before, this tool chains with Nerva, and that’s how it becomes useful to test the entire infrastructure against common password and detection.
Julius
With AI services proliferating inside corporate environments, we want to know what LLM infrastructure is running on our hosts. Julius will fingerprint more than 60 AI services including Ollama, vLLM, LiteLLM, LocalAI, Hugging Face TGI, AWS Bedrock and AnythingLLM. It can also list available models from endpoints.
kali > curl -sL -o julius.tar.gz https://github.com/praetorian-inc/julius/releases/download/v1.5.1/julius_1.5.1_linux_amd64.tar.gz
kali > tar --no-same-owner -xzf julius.tar.gz
kali > ./julius --help
You can list all the AI services Julious can fingerprint:
kali > ./julius list
We will take a look at our machine.
kali > ./julius probe http://192.168.131.7:11434
Ollama sits on port 11434, and it’s important not to leave it exposed publicly, because everyone can use your models without authentication.
Summary
There are more tools available in this project. Most of them are meant to be chained together and work well this way. The company says its team is actively using these same tools during their engagements. While you won’t need everything at once, experiment with those tools and see what fits you best.
If you like red teaming, we have our Red Team Operator training, where we cover more tools and techniques to help you emulate real APT work, so you can give a company a realistic stress test and help make it secure.
Welcome back, aspiring cyberwarriors and bug bounty hunters!
Hacking web applications nowadays requires not just a well-written exploit but also a way to bypass a Web Application Firewall (WAF). Despite being a staple of modern security architecture, WAFs are often misunderstood: they are usually treated as magic shields when, in fact, they are complex systems with strengths, limitations, and blind spots.
In this article, we will cover three core topics: WAF operation, WAF fingerprinting methods, and bypass techniques. Let’s get rolling!
Understanding Web Application Firewalls and Detection Logic
A Web Application Firewall (WAF) is a security tool that sits in front of your web app and checks every incoming request before it reaches your code. It operates at Layer 7 of the OSI model, the application layer where HTTP traffic lives. Unlike traditional network firewalls, a WAF looks at the actual content of requests, like headers and URLs, not just their source.
WAFs typically use three methods to assess requests.
First is signature-based detection, similar to antivirus software. The WAF compares incoming requests against a list of known attack patterns and blocks any matches. This method is fast and effective for common attacks, but it can miss variations.
Next, anomaly scoring assigns points for various suspicious elements within a request. When the total score exceeds a threshold, the WAF blocks the request. This method is flexible because a single odd detail isn’t concerning, but a combination is.
Finally, behavioral detection focuses on client activity over time. The WAF monitors request rates and patterns and shuts down suspicious behavior like automated login attempts, even if each request seems harmless.
Combining these strategies gives a WAF a strong understanding of traffic, making it a key defense for serious web applications.
Fingerprinting a WAF
Before you do anything with the target, it’s smart to see whether they’re using a WAF at all. A good first step is to check the web application’s headers. You can easily do this with the curl command. Just type:
kali> curl -I target.com
In the screenshot above, we can see that the site uses Cloudflare and Qrator’s WAF. Usually, you can spot some hints in the headers that help identify it, like:
The unique transaction tracking ID: X-Qrator-Request-ID or X-Qrator-Req-ID
Server header showing: Server: QRATOR
Internal proxy metadata headers like X-Qrator-IP or X-Qrator-Upstream.
Another way to fingerprint the WAF is through behavior analysis. Here, we’re not just loading a webpage, but we send something that seems a bit malicious. For example, let’s try executing a random HTTP method:
When you run into a 418 status code along with kittenx, it’s usually the edge layer stepping in as a bot-mitigation tool or a WAF block. This means that the incoming request hit a security rule, hit a rate limit, or didn’t pass automated fingerprint checks. Most of the time, you’ll see a 403 status code, which is the classic WAF block. Sometimes you might see other codes like 406, especially with ModSecurity CRS. Some vendors even show their own “Access Denied” HTML page when this happens.
Instead of using curl to trigger different WAF rules manually, a cool tool called WAFW00F can do the identification for you. It starts by sending a normal HTTP request and checking the response to see which WAF solutions it can spot. If that doesn’t work, it sends potentially malicious HTTP requests to figure out which WAF is in play. If that still doesn’t yield results, it looks back at previous responses. It uses straightforward logic to guess whether a WAF or security tool is responding to its efforts. This tool is actually preinstalled on Kali Linux, so you can easily check it out by running:
kali> wafw00f -h
WAFW00F can spot plenty of firewalls. If you want to see the full list, just run this command:
kali> wafw00f -l
You just need to throw a URL in as an argument to get started.
Common WAF Bypass Techniques
Web apps handle lots of encoded text, and problems arise when they decode that text multiple times or in the wrong order compared to what a WAF expects.
For example, double URL encoding can create vulnerabilities. If you encode a single quote twice as %2527, the WAF sees that and thinks it’s safe. But once the app decodes it twice, it turns into a real single quote, slipping past the WAF. This often leads to XSS.
Unicode normalization can also be tricky because characters can appear in different ways. For example, if a WAF looks for < (U+003C) but gets the full-width version (U+FF1C), it won’t catch it. When the app normalizes it back to <, it creates a vulnerability.
Then there is ASCII smuggling, where attackers use invisible Unicode tags (U+E0000 to U+E007F) to replace plain ASCII characters. To the bare eye or even a WAF, it looks like a space in a regular message. But when the application decodes those tags, the hidden payload shows up intact and ready to execute. It is all about hiding real characters behind an invisible disguise.
With the popularity of AI, we also encounter a new type of vulnerability. If an AI model doesn’t have appropriate security guidelines, ASCII manipulations can lead to data poisoning.
Summary
There are tons of ways to get past a WAF without being noticed. In this article, we quickly covered what a WAF is, how it works, and how to identify which WAF you’re dealing with so you can test specific bypass techniques. In a future article, we’ll cover automated solutions. Stay tuned!
You’ve probably seen people committing their env files to GitHub without noticing it. When you’re looking for a job as a coder, that mistake alone is significant enough to get you rejected if it happens during the technical portion. And if it ever happened to you, it’s happened to plenty of others too.
Today we’ll look at TruffleHog. It’s a tool that scans Git repositories and their full history for secrets that got committed by accident. It uses high entropy checks with custom regular expressions to catch strings that look like API keys, tokens, passwords and other sensitive data. You can point it at one repository or use a GitHub or GitLab API to hit a lot of projects in one go.
A developer can delete a key from the latest commit, but it will still live in Git’s past. With those credentials, you access services without making much noise.
Installation
First install git-dumper and TruffleHog. The Python package and the GitHub release are not the same, so pay attention to which one you’re on.
kali > pip3 install git-dumper
kali > pip3 install trufflehog
We’ll use git-dumper when we find an exposed .git directory and then run TruffleHog against that dump. Leaked .git folders are still common.
Dump a Repository
Some servers leave the entire .git directory open. Below you can see a website where it was fully accessible.
Dump it by giving git-dumper the URL and a local folder for the files.
kali > git-dumper http://example.com/.git dump
Other websites block the directory listing but still serve some of the files.
Git-dumper can pull every object, commit and reference it can reach.
kali > git-dumper http://example.com/.git/ dump
Everything will be stored in the dump folder.
Analyzing the Repositories
Once the dump is on disk, run TruffleHog against it. By default it runs entropy-based matching. That can help, but it shouldn’t be the only mode you know. In our case, regex with entropy off gave us more results.
kali > trufflehog --regex --entropy NO dump
In one of the files we found database credentials.
You can also install TruffleHog from the GitHub release and scan the filesystem directly:
kali > curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin
kali > trufflehog filesystem /home/kali/Documents/dump
This build is fine for tuning your scans, but it often makes more noise and false positives, so just be aware of it.
Other Ways to Analyze Repositories
Depending on which build you’re using, try these flags to change what you get in the output.
Scan a repo for verified secrets:
kali > trufflehog git https://github.com/trufflesecurity/test_keys --results=verified,unknown
Verified means TruffleHog checked these finding live against the service API (AWS, GitHub and so on). Unknown is both high entropy and regex hits that it couldn’t confirm.
Same scan with JSON output:
kali > trufflehog git https://github.com/trufflesecurity/test_keys --results=verified,unknown --json
Scan a GitHub repo including issues and pull requests:
kali > trufflehog github --repo=https://github.com/trufflesecurity/test_keys --issue-comments --pr-comments
That digs into issues, comments, PR bodies and comments. You can find leaks in discussions too.
Scan a local Git repo:
kali > trufflehog git file://test_keys --results=verified,unknown
Useful when you’ve compromised a dev Linux machine with multiple projects on it. There’s a better chance of finding something locally than pushed to GitHub, although both can happen, as you now know.
Summary
We had an external pentest where several services were accessible but no credentials could be found. Surprisingly, some developers had kept projects they were doing for the company publicly accessible on GitHub. Eventually we found a working pair and got into a database.
TruffleHog can be really helpful here. Sensitive files sometimes get exposed without the publisher even knowing it. We’re humans and we make mistakes. Offensive or defensive, the point is the same.
Welcome back, aspiring cyberwarriors and bug bounty hunters!
When we work with web applications, we often need to effectively crawl and spider them to understand what we’re dealing with. But the main problem we might encounter is that a target web app is an SPA, or single-page application. This means that the website loads a single HTML file initially and dynamically updates the content within that page as the user interacts with it. Therefore, traditional crawling tools become ineffective with modern web applications.
To work with modern JavaScript frameworks, single-page applications, and sophisticated authentication mechanisms, we can use the Katana framework from ProjectDiscovery. Katana is a web crawler that allows you to discover hidden paths, parameters, and endpoints in web applications. It’s fast, modular, and supports multiple crawling techniques.
One of the most impressive aspects of Katana is its ability to handle JavaScript execution and dynamic content rendering. Traditional crawlers often miss critical functionality because they cannot execute JavaScript or understand how modern web applications dynamically generate content. Katana addresses this limitation by incorporating headless browser capabilities that allow it to fully render pages, execute JavaScript, and discover content that would otherwise remain hidden.
Let’s explore how to download, install, and utilize this powerful reconnaissance tool to enhance your web application security testing capabilities.
Installing Katana
There are few methouds of installing the tool. In this article, I’ll focus on installing using Go programming language.
First, verify if Go is already installed:
kali> go version
Install Katana using the Go package manager:
kali> go install github.com/projectdiscovery/katana/cmd/katana@latest
Verify the installation:
kali> katana -version
Crawling Modes
Katana supports two main crawling modes, each tailored to different types of web applications and use cases.
The Standard Mode is designed for speed and simplicity, making it ideal for traditional websites. It uses Go’s built-in HTTP library to handle requests and responses, parsing raw HTTP response bodies without executing JavaScript or rendering the DOM. This lightweight approach ensures fast performance but may miss endpoints in more complex applications that rely on browser-based events.
In contrast, the Headless Mode offers a more thorough crawl by simulating a real browser environment. This mode is especially useful for modern, JavaScript-heavy applications, as it captures both raw and rendered content. By mimicking a legitimate browser fingerprint (including TLS and user-agent headers), it improves coverage and detection of dynamic elements.
You can enable Headless Mode with the -headless flag and customize it further with several options:
-sc / -system-chrome: Use the locally installed Chrome
-sb / -show-browser: Show the browser window during execution
-nos / -no-sandbox: Disable the Chrome sandbox (useful for root users)
-cdd / -chrome-data-dir: Specify a custom Chrome data directory
-scp / -system-chrome-path: Set a specific path to the Chrome executable
-noi / -no-incognito: Disable incognito mode
Basic Website Reconnaissance
Let’s start with a fundamental reconnaissance scenario where we need to map a target website’s structure and discover all accessible endpoints. For this example let’s try to understand application’s structure of Vesti.ru – Russian news website.
-js-crawl: Enables JavaScript execution during crawling to handle AngularJS controllers and directives
-headless: Uses headless Chrome for rendering AngularJS templates and executing digest cycles
-timeout 30: Sets 30-second timeout for page loads to accommodate AngularJS bootstrapping
-delay 2: Adds 2-second delay between requests to allow AngularJS routing transitions
Known Files Discovery
Crawl for common files like robots.txt and sitemap.xml that often reveal valuable information about website structure and hidden content. These files can provide insights into:
robots.txt: Disallowed directories and files that may contain sensitive information
sitemap.xml: Complete site structure including pages not linked from main navigation
Other discovery files: Common configuration files, backup files, and administrative interfaces
kali> katana -u https://example.com -known-files all -d 3
Note that a minimum depth of 3 is required to ensure comprehensive discovery of all known files across the target application.
Filtering Capabilities
Katana offers robust filtering features that help users process, refine, and manage crawl output with precision. These capabilities make it easy to isolate valuable data, reduce noise, and tailor results to match specific goals.
Users can filter output by specific fields, include or exclude URLs based on extensions or regular expressions, and even define custom fields using a YAML configuration file. This flexibility is crucial for handling the often large volume of data produced during a crawl, ensuring that users can focus on the most relevant information.
Some key filtering options include:
-field or -f: Display specific fields (e.g., url, path, fqdn, rdn)
-store-field or -sf: Save selected fields to disk
-extension-match or -em: Show only URLs with specific file extensions
-extension-filter or -ef: Exclude URLs with specific file extensions
-match-regex or -mr: Include URLs that match a regex pattern
-filter-regex or -fr: Exclude URLs that match a regex pattern
Example: To extract only .js URLs (including those with query parameters) and save their full URLs to a file, you could run:
Whether you’re conducting penetration tests, bug bounty research, or comprehensive cyberwar operations, Katana’s advanced capabilities and modern architecture make it an essential addition to your hacking toolkit.
If you’re serious about sharpening your offensive security skills, consider our Subscriber Pro package. It’s designed to take your expertise to the next level.
Lately, we’ve covered several tools you can use with your laptop to track nearby devices and people. While they’re useful, their effectiveness depends on the strength of your Bluetooth adapter, and, of course, you need to have your laptop with you.
This time, we’re doing things differently. We want to show you a device that can automatically monitor nearby devices for extended periods, anywhere you choose to place it, and as often as you want. It doesn’t rely solely on Bluetooth, as it also uses Wi-Fi, which is far more likely to be enabled, increasing the chances of detecting someone in your area.
What is Paxcounter
Paxcounter is an open-source firmware project that takes a cheap little ESP32 development board and turns it into a sensor that can count people. Almost every smartphone in the world is constantly sending out small Wi-Fi signals, called probe requests, and Bluetooth signals too, even when the phone is not connected to anything. Paxcounter listens for these signals in the air. It counts how many different devices it hears during each scan, and from that, it can tell you a real time estimate of how many people are nearby.
The project started out as a simple way to measure how many passengers or pedestrians pass through a certain spot. But over time, it grew into something much bigger. Now it works as a general purpose IoT platform, built on hardware that usually costs somewhere between $10 and $30. Besides its main job of counting Wi-Fi and Bluetooth devices, a Paxcounter can also read environmental sensors, track its GPS position, keep accurate time, and send all of that data out through LoRaWAN, MQTT, a local serial connection, or straight onto an SD card.
How the Counting Works
The way Paxcounter counts people is simple, but it was clearly built with privacy in mind from the very start. Every scan cycle, which lasts 60 seconds by default, the device switches its Wi-Fi and Bluetooth radios into scanning mode and listens for probe requests and advertisement packets coming from nearby devices. Each of these packets carries a MAC address. Paxcounter takes just the last two bytes of that address and turns them into a short, temporary ID. This ID is only used to check for duplicates during that one scan cycle. Once the cycle ends, the count of unique IDs gets sent out, and the whole list is wiped from memory. The firmware also does not try to fingerprint any device. It never tries to figure out a phone’s brand, its operating system, or who owns it. All it wants to know is whether that device has already been counted in the current window.
This scan and clear cycle just keeps repeating, either nonstop or on a schedule if deep sleep power saving is turned on. The results, which include the Wi-Fi count, the Bluetooth count, and sometimes live sensor readings too, get packed into a small payload and sent out through whatever channel the device is set up to use. One thing worth knowing is that Wi-Fi and Bluetooth scanning actually share the same 2.4 GHz radio hardware on the ESP32. So running both scans at the same time slightly lowers the accuracy of each one. Because of that, the project’s own advice is to split Wi-Fi only counting and Bluetooth only counting across two separate devices whenever the best possible accuracy is needed for both.
One Firmware, Many Boards
Paxcounter comes with a hardware abstraction layer and its own pin mapping files for dozens of ESP32 and ESP32-S3 boards. These come from well known manufacturers like LILYGO and TTGO, Heltec, Pycom, WeMos, M5Stack, and Adafruit, and there is also a generic template ready for boards that are not officially supported yet. LILYGO even sells a ready-made board called Paxcounter LoRa, built specifically to run this firmware.
Depending on which board you pick, your device can end up supporting a LoRaWAN radio for sending data over long distances while using very little power, an OLED status screen, or a single color, RGB, or larger LED matrix light to show status. It can also support a physical button for flipping through display pages or sending an alarm message, battery voltage monitoring, GPS positioning, a real time clock chip along with IF482 or DCF77 time telegram output, and even an SD card slot for logging data locally when there is no network around.
Because the whole system was designed to be truly portable, the documentation goes into real detail about power draw, which usually sits somewhere between 450 and 1000 milliwatts depending on how the device is set up. It also makes good use of the ESP32’s deep sleep mode, so a device can keep running for a long stretch of time on just one 18650 lithium ion battery cell. Members of the community have already shared several 3D printable enclosure designs on Thingiverse for the more popular boards.
Getting the Device Up and Running
Paxcounter is built using PlatformIO instead of the plain Arduino IDE. This choice lets it work smoothly with editors like Visual Studio Code, Atom, or Eclipse, and it gives the project reproducible, script driven builds. In fact, the repository runs an automated PlatformIO build check every single time the code changes, using GitHub Actions, and there is even a CodeFactor badge that keeps an eye on ongoing code quality.
The configuration is intentionally spread across a handful of different files instead of being crammed into just one. This keeps board specific settings, behavioral settings, and personal settings nicely separated from each other. The platformio.ini file is where you select which board’s hardware profile you want to compile against. The paxcounter.conf file handles behavioral settings, things like how long a scan cycle lasts, sleep timing, and payload options. The shared lmic_config.h file sets the LoRaWAN region and frequency plan, so it matches the rules where you live. The shared loraconf.h file holds the device’s LoRaWAN join credentials, and the project recommends using OTAA rather than ABP for this. And the shared ota.conf file stores the Wi-Fi credentials the device uses for over the air firmware updates.
You can upload firmware the traditional way, over USB, or once a device has joined a LoRaWAN network, you can push updates over the air instead. A remote command tells the board to connect to Wi-Fi, check a hosted repository called PAX.express for a newer build, and then download and flash it automatically. If anything goes wrong during that process, it will roll back to the previous version on its own. Devices can also be set up to open a small local web based bootstrap menu right when they power on, which lets you upload a firmware file manually, even from a phone in tethering mode, without needing PlatformIO installed on site.
Configuration and Extensibility
Beyond just picking a board, Paxcounter gives you a long list of settings you can tune to fit your needs. It can log environmental data from sensors like the Bosch BMP180, BME280, BMP280, or BME680, read a Nova SDS011 particulate matter sensor to track dust in the air, and keep accurate time using either a DS3231 real time clock or a connected GPS module.
Display and LED
On boards that come with an OLED display, Paxcounter shows live status information you can cycle through with a short press of the button. This includes the current pax count, meaning the people count, a histogram of recent activity, GPS status, environmental sensor readings, and the time of day.
A long press of that same button sends an alarm message out over the network instead, which is a simple way to flag a problem from out in the field without needing any other kind of interface. Even on boards that do not have a display at all, a status LED still tells you what the device is doing through its blink pattern. You get a brief flash whenever a new Wi-Fi or Bluetooth device is spotted, a quick blink while the device is joining the LoRaWAN network, a short blink during data transmission, and a slow, long blink if there is a LoRaWAN stack error. Boards that have an RGB LED get a color coded version of these same signals.
How You Receive the Data
Once a Paxcounter has counted the people nearby and packed everything into a message, that data has to go somewhere so you can actually see it. How that happens depends on which output the device is using, and the good news is you can turn on more than one at the same time. If you are using LoRaWAN, which is the most common setup, the device does not send the data straight to you. Instead, a nearby LoRaWAN gateway picks up the signal first and forwards it on to a network server, usually The Things Stack. There is a small decoder script included with the project, and its job is to take that raw message and turn it into numbers you can actually read, something like a pax count of 14. From there, The Things Stack can pass the data along to your own app or dashboard using MQTT or a webhook, or you can simply watch it come in live through the built in console.
If a board does not have LoRa hardware built in, it can just skip the gateway completely and send that same kind of data straight to an MQTT service over Wi-Fi instead. You can also connect the device to a computer using a USB cable and read the numbers directly from a serial connection. This is a simple way to test things out without needing to set up a network at all. If SD card logging is turned on, everything also gets saved locally as a CSV file, so you can pull the card out later and open it up in a spreadsheet. This comes in handy in places where there is no network coverage to rely on.
Where It’s Used
Because a single Paxcounter device is cheap to build and can be left running unattended for a long time, you will find it popping up in a pretty wide range of places. Retailers and shopping centers use it to measure foot traffic without needing to install cameras. Event organizers use it to watch how crowds move around a venue in real time. Pentesters can get a passive read on how many Wi-Fi and Bluetooth devices are active in a building, or to notice unexpected devices showing up where they shouldn’t, all without needing camera access or network credentials.
Legal and Privacy Considerations
Since Paxcounter’s whole job involves listening to wireless traffic, its documentation is unusually upfront about the legal side of things. It points out that sniffing Wi-Fi and Bluetooth MAC addresses may be regulated or restricted depending on where you live, and it links to specific starting references for the US, the UK, the Netherlands and the EU, and Germany. It also makes clear that the legal responsibility for how a device is built and deployed falls on the person doing it, especially for public deployments where the results might get published somewhere. On the technical side of privacy, the project’s own design actually holds up pretty well against that legal backdrop. Identifiers are only ever built from the last two bytes of a scanned MAC address, they are kept in memory just for the length of one scan cycle, and then they are discarded completely. No MAC addresses or identifiers are ever sent out over the network, and the firmware does not do any extra tracking or fingerprinting of the devices it scans.
Summary
What really makes Paxcounter stand out is not any single feature on its own. It is the whole combination working together. One piece of open source firmware supports dozens of cheap boards, runs for a long time on a small battery, counts people without saving anything identifying about them, doubles as a general environmental sensor node, speaks LoRaWAN, MQTT, serial, and SD card all at once, and can be fully reconfigured from a distance once it is out in the field. The full source code, the complete board list, and all the documentation are available on GitHub.
If you enjoy experimenting with frequencies and trying new things, we recommend signing up for our SDR for Hackers training. With Master OTW, you’ll learn how to use your computer and inexpensive SDR hardware to explore and hack a wide range of radio signals.
During pentests, it’s not uncommon to find a Grafana somewhere inside an organization’s infrastructure. Sometimes it can even be exposed directly to the Internet. It’s always worth checking Grafana for vulnerabilities, as it has been affected by multiple security issues over the years.
What is Grafana
Grafana is an open-source monitoring and visualization platform used by organizations to display dashboards containing information collected from servers, applications, databases, cloud services and networking equipment. Administrators rely on it to monitor the health of their infrastructure in real time, making it one of the most widely deployed monitoring apps in enterprise environments. Since Grafana often connects to numerous backend services and contains valuable configuration information, compromising it can sometimes give hackers an excellent foothold into the rest of the network.
Of course, you could manually inspect every Grafana installation looking for known vulnerabilities, but that quickly becomes time-consuming, especially during larger engagements where multiple servers have to be assessed.
Fortunately, there is a Grafana-Final-Scanner. It’s a tool designed specifically to automate this process. Instead of manually checking every instance the scanner performs the work for you by checking whether the target is vulnerable to a collection of publicly known vulnerabilities.
Grafana-Final-Scanner
We’ll begin by downloading the repository and installing its dependencies.
kali > git clone https://github.com/Zierax/Grafana-Final-Scanner.git
kali > cd Grafana-Final-Scanner
kali > python3 -m venv venv
kali > source venv/bin/activate
kali > pip3 install -r requirements.txt
Once everything has been installed successfully, it’s worth taking a quick look at the list of vulnerabilities supported by the scanner.
At the time of writing, the tool is capable of checking for more than fifteen different Grafana vulnerabilities.
Now let’s point it at our target.
kali > python3 scanner.py -u https://target/grafana/login
After a short scan, the tool analyzes the target and reports any vulnerabilities it successfully identifies.
In our case, the results were promising. The scanner identified CVE-2024-8118 and an OAuth Authentication Bypass vulnerability. It also gave us the URL. We opened the page and the application asked us for an administrator key that we obviously didn’t have.
Fortunately, web applications don’t always behave exactly as their developers intended. Developers occasionally leave sensitive information inside the application’s front-end code. JavaScript, HTML comments, hardcoded credentials, authorization logic have all been discovered by hackers countless times over the years.
With that in mind, we opened the page’s HTML source code to see exactly how the authorization process was implemented. The comments were written in Russian, but the logic itself was fairly easy to understand.
Instead of verifying a specific administrator key, the application simply checked whether any key existed. So the validation routine wasn’t actually validating the value at all. It simply checked if some key was provided.
The next step was straightforward. We opened the browser’s Developer Console and manually created the expected key.
The application accepted it.
We bypassed the authentication and accessed the admin panel.
Finding a vulnerability is only part of the pentest. Understanding how the application behaves after exploitation is equally important. Sometimes the scanners get you only halfway there, while manual analysis can help you find the remaining pieces needed to fully demonstrate the impact.
It’s also a good reminder that developers occasionally leave sensitive information hidden inside client-side code. You never know what useful information may have been left behind.
Web Interface
While running the scanner from the command line works perfectly for testing targets, the project also includes a convenient web interface.
This can be useful during larger pentests where dozens of Grafana instances need to be assessed.
You can start it with this command:
kali > python scanner.py --serve --db vulndb.json
Summary
Grafana is one of the most common monitoring platforms you’ll encounter during internal and external penetration tests. Because it frequently contains sensitive operational data and often communicates with numerous backend systems, compromising it can sometimes provide hackers with an excellent entry point into an organization’s network.
Grafana-Final-Scanner can make it much easier to determine whether your Grafana is exposed to known vulnerabilities.
If you enjoy web application pentesting and would like to improve your skills for bug bounty hunting, we have our Web Application Hacking training. You’ll gain the practical knowledge and skills you need to start finding web application vulnerabilities.
Login
