In autumn 2025, KittenBusters published a large collection of operational documents and malware samples tied to Charming Kitten, an espionage group associated with Iran’s Islamic Revolutionary Guard Corps. The release offered an unusual view into the group’s tools, internal documentation, and working methods.

RaazNet began with the most urgent question: who had been infected? That work led to the identification and notification of victims, including an activist and journalist in Toronto whose computer had been compromised. Our later reporting examined RAT 2Ac2, a modular Windows Trojan, and Kashef, a surveillance system that brings several categories of citizens’ data into one interface. We also traced the wider Charming Kitten operation and its use of AI generated decoy material.

This report focuses on another tool in the collection. Saqeb is described in the leaked material as malware made specifically for Windows systems. Three files are central to understanding it: The Saqeb system manual, A technical description of 13 malware families, and An Encryptor V1 test report

The main manual carries the name of the Ofoq Media Institute. On its own, a name on a cover would prove little. In this collection, however, it appears alongside other records that connect the institute to Iranian security bodies. Its presence therefore belongs in the attribution trail and should not be treated as a decorative credit.

According to the manuals, Saqeb was built to maintain access to Windows computers and servers, collect information, and destroy files in ways intended to prevent recovery. The stated targets include systems holding classified or operationally sensitive material, databases used by public and private organizations, and computers belonging to senior officials or other valuable targets.

What the Saqeb documents reveal

Saqeb is presented as a control and espionage system, not a lone program with one narrow task. A client installed on the victim’s device communicates with infrastructure used by operators to issue commands, retrieve data, and activate additional functions. The client is meant to remain available after the initial infection rather than run once and disappear.

The documented capabilities include:

• Remote command execution
• Access to and theft of files
• Keylogging
• Screen capture
• Collection of information stored by applications
• Removal of collected data from the victim’s system
• File destruction

Two modules deserve particular attention. One targets Telegram session data. If an operator obtains a valid session, the victim’s account may be accessible without the password normally required for a new login. Another module extracts information and saved passwords from Firefox, potentially opening a path to email, social media, cloud storage, and any other service whose credentials were kept in the browser.

The management panel is just as revealing as the theft modules. The documents refer to operator accounts, user controls, event logs, and support for different client builds. Those features make sense in an environment where several people manage several compromised machines and need a record of what each operator has done. Saqeb was designed as working infrastructure for continuing espionage, not as a throwaway tool for one intrusion.

Four core design challenges

A section of the manual titled Challenges and Design Considerations for Saqeb Malware sets out the practical problems behind the design. The developers were concerned with detection, software dependencies, exposed communications, and the privileges available on a victim’s computer. Measures intended to slow analysis and debugging appear throughout these discussions.

1. Staying ahead of detection: Fully Undetected (FUD)

The manual uses the term Fully Undetected, or FUD, in the sense common among malware developers. The goal is to deploy a sample before antivirus signatures or detection rules recognize it. If Windows Defender or another security product blocks the file during delivery or soon after execution, the operation may fail before the attackers establish access.

The developers claim they avoided fixed patterns that would be easy to turn into signatures. They also describe obfuscation, delayed execution, and changes in program behavior. Each tactic is meant to buy time: enough for the malware to run, connect, and collect useful information before defenders understand what they are seeing.

FUD is not a permanent quality and the label should not be read as proof of invisibility. Detection changes when researchers obtain a sample and security vendors update their products. Here, the term records an operational ambition at the time of deployment, not a test result that can remain true indefinitely.

2. Running without extra software: Framework independence

Malware that relies on a particular runtime may fail on a target where that component is missing or incompatible. Installing it can create errors, prompts, or other activity that draws attention. The Saqeb developers wanted one client to run across several versions of Windows without asking the victim’s system for additional prerequisites.

The manual points to native implementation choices and technologies that can produce a standalone executable. Reducing dependencies does not make the malware more capable by itself. It makes deployment less fragile and expands the range of systems on which the same build may work without obvious installation activity.

3. Hiding the route back to the operator

A persistent command and control channel can expose far more than one infected computer. Defenders may use destination addresses, traffic patterns, and transmitted content to identify a server, find related victims, or map other parts of the operation. Saqeb’s documentation describes two ways to reduce that exposure.

The first is to keep captured data from travelling in directly readable form. The manual refers to XOR transformation or encryption. With a predictable key, XOR is weak cryptography and is more accurately described as obfuscation. Even so, it may prevent a casual inspection from revealing the content immediately.

The second is to route communications through Tor or intermediary systems. An infected machine would not necessarily contact the operator’s main server directly. That separation makes the final destination harder to locate and limits what defenders can learn if they identify or take control of one relay.

4. Obtaining administrator access: Privileged access

The manuals treat administrator access as a condition for using Saqeb’s full range of functions. What the malware can reach depends on the privileges of the person who opens the infected file.

Elevated access can expose protected areas of Windows, broaden access to other users’ information, permit interference with security controls, and enable destructive actions that an ordinary account could not perform. This also means the platform’s capabilities on paper may exceed what it can do on every infected machine. The documents reviewed here do not establish how each operation obtained the necessary privileges.

The security principles behind Saqeb’s design: Security for the operation, not the victim

The word security carries an inverted meaning in Saqeb’s internal documentation. It refers to protecting the operation, its operators, and their infrastructure. The victim’s security is the obstacle the platform is trying to defeat.

Several operational-security principles can be inferred from the architecture:

• Reduce the detectable surface: Avoid simple, fixed file, behavioral, or network patterns that defenders can turn into reliable signatures.
• Reduce dependence on the victim’s environment: Make the client executable across a wider range of Windows systems without additional components.
• Separate the victim from the real command-and-control server: Prevent the compromise or analysis of one infected system from immediately revealing the operator’s primary infrastructure.
• Protect data and its transmission path: Make intercepted traffic harder to interpret and trace.
• Resist analysis: Use obfuscation, delayed execution, and related techniques to slow investigation after discovery.

That logic appears across the design. Avoiding stable file and network patterns reduces what defenders can convert into signatures. Limiting software dependencies helps the client run on more machines. Intermediaries separate victims from the main control server. Obfuscation slows inspection of code and traffic. Operator accounts and event logs bring the same discipline into the management panel.

The centralized management layer extends this operational-security model beyond the victim’s device. A control panel, operator accounts, user management, and event logging allow multiple compromised systems to be managed from a controlled environment while recording the actions taken by different users.

These details distinguish Saqeb from a basic remote access Trojan. They make it an operational platform for persistent espionage. The design aims to run on more systems, remain undetected for longer, make communications harder to trace, and complicate analysis after discovery. Those priorities align closely with Saqeb’s stated mission: persistent access to sensitive information, organizational databases, and the computers of high-level targets.

The leaked files do not show how widely Saqeb was deployed, and a feature described in a manual should not automatically be treated as a feature proven to work in the field. What the files do show is the system its developers intended to build: a Windows surveillance platform that could stay available, accept new tasks, collect several kinds of information, and make the path back to its operators difficult to follow. That combination, rather than any single module, is what makes Saqeb significant.