Operation XENOFISCAL: SideCopy deploying persistent XenoRAT targeting the MoF, Afghanistan

Authors: Dixit Panchal & Vaibhav Krushna Billade

Table of Contents:

• Introduction:
• Key Targets:
• Infection Chain:
• Initial Findings about Campaign:
• Analysis of Decoy:
• Technical Analysis:
  • Stage 1: Analysis of LNK File.
  • Stage 2: Analysis of HTA/JavaScript Payload
  • Stage 3: Analysis of Stage-1 Loader DLL
  • Stage 4: Analysis of Stage-2 Loader DLL and Shellcode
  • Stage 5: Analysis of XenoRAT.
• Infrastructural Artefacts & Threat actor Attributions.
• Conclusion: Operation XENOFISCAL?
• Seqrite Coverage:
• IOCs:
• MITRE ATT&CK:

Introduction:

Seqrite Labs has been actively monitoring spear phishing campaigns across the globe and has a well-established history of tracking the SideCopy APT cluster — a Pakistan-linked threat group operating under the broader Transparent Tribe / APT36 umbrella. In continuation of that tracking effort, we identified a targeted campaign directed at the Ministry of Finance, Afghanistan, with TTPs that overlap with SideCopy at medium-to-high confidence.

The campaign opens with a spear phishing delivery — a ZIP archive containing a malicious LNK file bearing a carefully crafted Pashto-language filename:

د_هغو_کارکوونکو_لېست_چې_د_فکري_او_رواني_جګړې_سیمینار_ته_ورپېژندل_شوي_وو12.pdf.lnk (“List of Employees Who Were Introduced to the Intellectual and Psychological Warfare Seminar”)

The choice of Pashto is deliberate. It is the dominant language across Afghanistan’s government institutions and the primary language of the intended targets — provincial finance officials operating across all 34 Afghan Mustoufiats. By framing the lure around a seminar on psychological and intellectual warfare, the actor demonstrated precise knowledge of the operational and administrative context of their targets.

What follows in this report is a full technical dissection of the campaign — from the LNK execution chain through to the XenoRAT implant beaconing to bulletproof European infrastructure — alongside infrastructure pivots, decoy document analysis, and attribution mapping against the known SideCopy TTP baseline.

Key Targets:

• Ministry of Finance, Islamic Emirate of Afghanistan.
• Provincial Revenue & Finance Directorates (Mustoufiats).
• Pashto-speaking government officials.
• Provincial-level government employees, not central ministry

Infection Chain:

Initial Findings about Campaign:

During our analysis, we observed the threat actor initiating the attack through a ZIP archive delivered via spear phishing, containing a malicious LNK file crafted in Pashto — a deliberate choice reflecting deep familiarity with the target environment.

Once executed, the LNK silently leverages mshta.exe to fetch a remote HTA payload from a compromised Afghan education domain, which decodes obfuscated JavaScript in-memory, establishes Registry-based persistence camouflaged as a Microsoft Edge entry, and ultimately deploys XenoRAT 1.8.7 — beaconing outbound to bulletproof European hosting infrastructure entirely separate from the delivery layer, ensuring long-term resilience.

Analysis of Decoy:

The decoy document dropped during execution is an Afghan Ministry of Finance provincial staff directory spanning all 34 provinces, listing Finance Directors, Revenue Chiefs, Financial Officers, and Secretaries alongside their direct mobile numbers — written entirely in Dari and Pashto.

The level of organisational detail suggests prior intelligence gathering by the threat actor. Its role in the attack is simple — while the victim reads what appears to be a routine internal government document, the malware has already silently completed its installation in the background.

Technical Analysis:

Stage1: Analysis of LNK File.

The LNK file acts as the initial infection vector and execution trigger within the attack chain. Although disguised with a PDF icon and misleading filename to appear as a legitimate document, inspection of its shortcut properties reveals that it launches the Windows utility mshta.exe from C:WindowsSystem32. The command embedded within the shortcut points to a remote malicious PHP resource hosted over HTTPS (hxxp[:]//<abimj.edu.af>/index.php), enabling the attacker to execute externally hosted script content directly in memory without dropping an executable to disk. By abusing mshta.exe — a legitimate Microsoft binary commonly associated with HTML Application (HTA) execution.

The attacker leverages a Living-off-the-Land Binary (LOLBIN) technique to evade traditional detection mechanisms and bypass user suspicion. The use of excessive comma obfuscation within the URL structure further indicates an attempt to hinder static analysis and signature-based detection.

Stage 2: Analysis of HTA/JavaScript Payload

The remote PHP payload retrieved through mshta.exe contains heavily obfuscated JavaScript code designed to execute malicious logic within the context of the HTA engine. Initial inspection shows the presence of encoded string arrays such as _$_f1bf=[“x55x33x6…”], a common obfuscation method used to conceal function names, URLs, commands, or secondary payloads from analysts and security tools. The script also defines deceptive window text such as “Windows File Error” to imitate legitimate system behavior and potentially distract the victim during execution. This stage serves as the primary execution and delivery layer of the campaign, where the obfuscated JavaScript is likely decoded dynamically to perform follow-on actions such as payload retrieval, command execution, persistence establishment, or data exfiltration.

Dissecting an Obfuscated JScript

Upon analysis, the .js file was identified as a heavily obfuscated JScript-based malware loader intended to execute under Windows Script Host (WSH) or legacy Internet Explorer environments with ActiveX support enabled. The script incorporates multiple malicious techniques, including ActiveX-based execution, custom Base64 payload decoding, .NET BinaryFormatter deserialization, and in-memory payload execution.

The first stage of the malware begins with a large, obfuscated JavaScript array, typically defined as a variable such as _$_f1bf, which contains numerous hexadecimal-encoded string fragments representing an embedded payload. These fragments are later concatenated and passed into a custom decoding function. Instead of relying on native Base64 decoding APIs, the script implements its own Base64 decoding routine to conceal the payload and hinder analysis.

The custom function dynamically reconstructs the standard Base64 character set (A–Z, a–z, 0–9, +, /) using String.fromCharCode, then processes the encoded data in chunks while rebuilding the original byte stream through a series of bitwise operations. By manually handling the decoding process, the malware avoids suspicious indicators such as atob() or common decoding libraries, making static detection and signature-based analysis significantly more difficult.

Payload Reconstruction Using .NET COM Objects

In the second stage, the malware converts the decoded payload into an executable in-memory object by leveraging multiple .NET classes instantiated through ActiveXObject. The script creates System.Text.ASCIIEncoding to convert the decoded string into a byte array, then uses System.Security.Cryptography.FromBase64Transform to perform an additional Base64 transformation on the payload. The resulting byte stream is written into a System.IO.MemoryStream object, effectively reconstructing the serialized payload entirely in memory without touching disk. This staged approach is commonly used in fileless malware because it allows attackers to prepare malicious .NET objects for execution while minimizing forensic artifacts and reducing the likelihood of detection by traditional file-based security products.

After decoding the embedded payload, the script enters its execution phase by creating a WScript.Shell ActiveX object, which enables access to registry operations, environment variables, and other system-level functionality. The script then checks whether the .NET Framework version v4.0.30319 is installed by querying the registry path HKLMSOFTWAREMicrosoft.NETFrameworkv4.0.30319. If the newer runtime is not available, it falls back to .NET v2.0.50727. The malware subsequently sets the COMPLUS_Version environment variable to force the process to load a specific CLR runtime version, ensuring compatibility with the embedded .NET DLL payload.

During execution, the malware abuses trusted .NET deserialization components including WPF XAML gadgets such as ObjectDataProvider and ResourceDictionary, along with Windows Forms serialization objects like AxHost and PropertyBagBinary. These components help maintain the deserialization gadget chain and trigger execution during object reconstruction.

Finally, the malicious serialized object stored within the MemoryStream object is processed through .NET BinaryFormatter.Deserialize_2(), enabling stealthy in-memory DLL execution while minimizing forensic artifacts and bypassing traditional file-based detection mechanisms.

Stage 3: Analysis of Stage-1 Loader DLL (Initial Loader)

This is a .NET loader DLL responsible for next-stage payload execution, persistence, and in-memory staging of the next components of the attack chain.

At start the openthefile() function which is responsible for downloading and opening a decoy PDF document from the URL hxxp[:]//abimj.edu.af/institute/cloudiyaf/document.pdf. The function first extracts the filename from the URL and saves the downloaded file into the Windows temporary directory using WebClient.DownloadFile(). Before initiating the download, the malware explicitly enables TLS 1.2 communication through ServicePointManager.SecurityProtocol, ensuring compatibility with secure HTTPS/TLS connections. After downloading the document, the malware pauses execution for five seconds and then launches the downloaded PDF file through a hidden command execution routine.

The RunProcessWithHiddenCmd() function is used to execute files or commands through cmd.exe. The function constructs a command-line argument using /c, which instructs cmd.exe to execute the supplied file path and terminate afterward. The function initializes a new process instance, assigns cmd.exe as the executable to launch, and passes the generated argument string to the process. Once started, the command interpreter executes the specified file or command and exits automatically after completion.

After opening the decoy document, the malware creates a directory named USOShared-1de48789-1285 under C:UsersPublic to store the next-stage HTA payload (zuidrt.hta). It then invokes the RegWorkExePathFromPublic() function which contains Base64-encoded registry commands that are decoded at runtime using the BSDSD94() base64 decoding routine. Once decoded, the command creates a new entry under the HKCUSoftwareMicrosoftWindowsCurrentVersionRun registry key with the value name Edgre. The registry entry executes:

cmd /C start C:UsersPublicUSOShared-1de48789-1285zuidrt.hta

To further ensure stealth and persistence, the malware writes the decoded command into a batch file named noway.bat in the user’s temporary directory and executes it via a hidden process. The execution is configured to suppress all visible windows, preventing any command prompt from appearing to the user. This ensures that the HTA payload is automatically launched during user logon, maintaining persistence on the system.

The CopyExeToUsersPublic() function is responsible for retrieving and reconstructing the next-stage HTA payload (zuidrt.hta) in the directory C:UsersPublicUSOShared-1de48789-1285. It first checks whether the target directory exists and creates it if it is missing using Directory.CreateDirectory(), further downloads the encoded payload from:

hxxp[:]//abimj.edu.af/institute/cloudiya/

The downloaded zuidrt.hta payload is stored in a compressed and Base64-encoded format to evade detection. The malware later decompresses and decodes the data to reconstruct the final HTA payload, which is executed through RunProcessWithHiddenCmd(), which internally runs cmd.exe /c start C:UsersPublicUSOShared-1de48789-1285zuidrt.hta, leveraging Windows file association to further invoke mshta.exe for HTA execution.

Execution of HTA Payload (zuidrt.hta)

The zuidrt.hta file follows a structure similar to the initial HTA payload but contains modified embedded components and updated execution logic. It continues the attack chain by reusing obfuscation and decoding routines to conceal its functionality and evade analysis. The script reinitializes ActiveX-based execution paths to maintain execution within the HTA environment and reconstructs the embedded serialized payload in memory.

Similar to the initial HTA stage, the payload leverages .NET deserialization components and gadget chains to trigger in-memory execution of the embedded Stage-2 loader DLL. This stage acts as a secondary execution layer within the infection chain, ensuring persistence of the attack workflow and facilitating the transition toward the next-stage DLL responsible for final payload delivery and execution.

Stage 4: Analysis of Stage-2 Loader DLL and Shellcode

After runtime decryption, execution flow is passed to a malicious DLL.

The DLL is a .NET-based shellcode loader responsible for retrieving, decoding, decompressing, and executing the next-stage payload entirely in memory. The malware uses multiple layers of staging and runtime execution to evade traditional security mechanisms and reduce disk-based artifacts.

The DLL acts as an intermediary loader between the JavaScript-based HTA stage and the final Xeno RAT payload.

Environment Setup and Payload Retrieval

Upon execution, the DLL initializes a staging environment designed to store and process the next-stage payload while minimizing suspicion. The malware first decodes a Base64-encoded string (ZmlyZWZ4LTFkZTg3ZWVjOC0xMjQx) using the custom BSDSD94() routine, resulting in the directory name firefx-1de87eec8-1241. It then creates a working directory under the publicly accessible Windows path:

• C:UsersPublicfirefx-1de87eec8-1241

The use of C:UsersPublic enables the malware to avoid privilege-related write restrictions while blending into legitimate filesystem activity. The directory naming convention mimics application-generated cache or profile folders, helping reduce user suspicion and evade basic IOC-based detections. The malware further defines temporary payload filenames such as ayui.vmxx and ayhui.vmxx, which are intentionally disguised using non-standard extensions to avoid immediate identification as executable content.

After establishing the staging directory, the DLL initiates outbound communication with attacker-controlled infrastructure to retrieve the next-stage payload. The malware contains multiple hardcoded URLs, including:

• hxxps[:]//abimj[.]edu[.]af/institute/10/
• hxxps[:]//abimj[.]edu[.]af/institute/7/

and dynamically selects the download endpoint based on the victim operating system version. Systems identified as Windows 7 (Version 6.1) are redirected to an alternate payload location, indicating compatibility-aware payload delivery.

Using the .NET WebClient.DownloadFile() method alongside explicitly enabled TLS/TLS1.1/TLS1.2 protocols, the malware downloads the encrypted payload and stores it locally as ayui.vmxx. The downloaded content is not directly executable; instead, it serves as an encoded and compressed staging blob that undergoes further Base64 decoding and GZIP decompression before shellcode execution is initiated in memory.

Payload Decoding and Shellcode Reconstruction

After successfully downloading the second-stage payload, the DLL stores the retrieved data within the staging directory as a disguised file named ayui.vmxx. Rather than deploying a portable executable (PE) directly to disk, the malware uses layered encoding and compression mechanisms to conceal the actual payload contents and evade static detection engines. The file contains Base64-encoded and GZIP-compressed data that appears non-executable during superficial inspection. This technique significantly reduces signature visibility for antivirus products and complicates manual analysis by preventing analysts from immediately identifying the payload format. The malware subsequently reads the entire file into memory using File.ReadAllBytes() and begins reconstructing the embedded payload dynamically during runtime execution.

The reconstruction process is handled through the custom decompressdata() function, which performs multiple decoding and decompression operations entirely in memory. The routine first decodes the Base64 blob, extracts the decompressed size header, and utilizes the .NET GZipStream class to restore the original payload buffer. Once decompression is completed, the resulting data is again passed through Convert.FromBase64String() to recover the raw shellcode bytes. The fully reconstructed payload is then written locally as ayhui.vmxx, which serves as the intermediate shellcode container prior to execution. By combining staged decoding, compression, and runtime payload rebuilding, the malware avoids exposing the final shellcode in plaintext form on disk, thereby bypassing conventional file-scanning and content-based detection mechanisms while preparing the payload for reflective in-memory execution.

Shellcode Execution:

Following payload reconstruction, the DLL transitions into the final execution phase by functioning as an in-memory shellcode loader. Instead of launching a traditional executable from disk, the malware directly allocates executable memory within the current process using the Windows API VirtualAlloc(). The allocation request uses the MEM_COMMIT flag alongside PAGE_EXECUTE_READWRITE (RWX) memory permissions, creating a memory region capable of storing and executing arbitrary code. This RWX allocation pattern is a well-known indicator of shellcode execution and reflective malware loading. After memory allocation, the malware copies the reconstructed shellcode buffer into the allocated region using Marshal.Copy(), effectively staging the payload entirely within process memory without relying on the Windows PE loader.

Once the shellcode is mapped into executable memory, the malware transfers execution to the injected buffer through the CreateThread() API, using the base address of the allocated memory as the thread entry point. This technique allows the shellcode to execute directly from memory, bypassing conventional disk-based execution monitoring and significantly reducing forensic artifacts. The DLL then invokes WaitForSingleObject() with an infinite timeout value to maintain thread synchronization and ensure uninterrupted shellcode execution. This execution methodology aligns with modern fileless malware tradecraft, where payloads are decrypted and launched dynamically in memory to evade signature-based antivirus engines, application control mechanisms, and static scanning technologies. The shellcode subsequently acts as the loader for the final Xeno RAT payload, enabling persistence, command-and-control communication, and remote attacker access on the compromised system.

The shellcode functions as an in-memory loader responsible for preparing and launching the final Xeno RAT payload.

During execution, it commonly performs environment validation, dynamic API resolution, and memory permission modifications using APIs such as VirtualProtect() and GetProcAddress(). In Donut loaders, the shellcode bypass security mechanisms by patching functions such as AmsiScanBuffer() to disable AMSI scanning and reduce visibility into dynamically loaded content.

Because the final payload is a managed .NET assembly, the shellcode initializes the .NET Common Language Runtime (CLR) by loading components such as clr.dll and mscoree.dll. The embedded payload is then decrypted and loaded directly from memory using reflective techniques such as Assembly.Load(byte[]), avoiding disk-based deployment entirely. Once loaded, the Xeno RAT payload executes in memory, enabling command-and-control communication, persistence, and remote attacker access on the compromised system.

Stage 5: Analysis of XenoRAT.

The final payload identified in the infection chain is Xeno RAT, an open-source Remote Access Trojan (RAT) publicly available on GitHub and commonly used by threat actors for persistent remote access, surveillance, and post-exploitation activities.

Upon execution, it initializes a secure command-and-control (C2) communication channel using a hard-coded IP address (185.235.137.106) and port configuration, allowing direct connection to the attacker-controlled infrastructure. To maintain single-instance execution and prevent multiple launches, the malware also employs a mutex (“clouda”), ensuring only one instance of the client runs on the infected system at a time. These initialization steps are followed by persistence and continuous reconnection logic to maintain long-term access to the compromised host.

Now , we will look into some of interesting function and analyze their functionalities.

ConnectAndSetupAsync function is responsible for establishing and initializing a TCP-based command-and-control (C2) connection between the client and the remote server. It creates a new Node instance using a SocketHandler configured with the provided socket and encryption key, enabling encrypted communication over the connection. After initialization, the function performs an asynchronous authentication handshake using AuthenticateAsync to validate the connection based on the supplied type and ID values. If authentication fails or an exception occurs during setup, the function returns null, indicating that the C2 communication channel could not be successfully established. Otherwise, it returns a fully initialized and authenticated Node object ready for secure data exchange.

DllNodeHandler function manages the dynamic loading and execution of external DLL modules received through a remote Node connection. It first receives the DLL name from the connected client and checks whether the assembly is already loaded in memory. If the DLL is missing, it requests the binary data from the remote side, loads it dynamically using Assembly.Load, and stores it in the Assemblies dictionary for reuse; otherwise, it informs the client that the DLL already exists. After loading, the function creates an instance of a specified class from the assembly using reflection and invokes its public Run method asynchronously, passing the active Node connection as an argument.

SendAsync method asynchronously sends data through the socket handler and verifies whether the transmission was successful, disconnecting the node if the send operation fails. Likewise, The ReceiveAsync method retrieves encrypted and formatted data from the underlying socket handler and returns the processed byte stream to the caller; if the operation fails or returns null, the node is automatically disconnected to maintain a valid connection state.  Together, these methods provide reliable TCP-based C2 communication with integrated connection management and automatic cleanup during transmission errors.

In addition, payload data is compressed using Windows native RTL compression APIs (RtlCompressBuffer) before transmission and decompressed using RtlDecompressBuffer on reception based on the original size header, improving transfer efficiency while preserving data integrity, while data security is enforced using AES encryption, where raw data is encrypted with a shared key and fixed IV via CryptoStream, ensuring secure communication during transmission.

Additional methods within the class manage other networking operations, including socket disconnection (Disconnect), establishing secondary sub-connections (ConnectSubSockAsync), validating active connection status (Connected), and maintaining child node relationships (AddSubNode).

AddToStartupAdmin function creates a Windows Scheduled Task named “XenoUpdateManager” that runs the specified executable automatically whenever a user logs into the system with the highest available (admin) privileges. It builds an XML task definition, writes it to a temporary file, and uses schtasks.exe to register the task in Windows Task Scheduler. After executing the command, it checks the output to determine whether the task was successfully created and then returns the result.

AddToStartupNonAdmin function adds the executable to the current user’s Windows startup by writing it into the HKCUSoftwareMicrosoftWindowsCurrentVersionRun registry key, so it runs automatically at login without admin rights, and returns whether the operation succeeded.

GetAntivirus function retrieves antivirus information from the system using Windows Management Instrumentation (WMI) by querying the AntivirusProduct class under rootSecurityCenter2. It collects the displayName values returned by this query, which represent installed antivirus products used for system identification.

RemoveStartup function removes an application from Windows startup by deleting any matching entries from both Scheduled Tasks (using schtasks.exe) and the registry key HKCUSoftwareMicrosoftWindowsCurrentVersionRun. It first checks for admin rights to remove scheduled tasks, then scans and deletes any task pointing to the given executable path. Finally, it removes any corresponding registry startup entry for the current user.

Uninstall function removes the application’s persistence mechanisms and then self-terminates the program. It first calls RemoveStartup to delete any startup entries (Scheduled Task or registry) associated with the current executable.

It launches a hidden cmd.exe process with a Base64-decoded command (/C choice /C Y /N /D Y /T 3 & Del) that waits for a few seconds and then deletes the running executable file from disk. Finally, the function forcefully kills the current process, ensuring the application exits immediately after cleanup.

Xeno-RAT CAPABILITIES

Xeno RAT reveals significant insight into its operational behavior and post-exploitation capabilities. Based on the analyzed code, observed activity, and functionality available in its open-source GitHub project, the malware demonstrates a wide range of features commonly associated with advanced remote access trojans (RATs).

• Monitors victim activity and collects host reconnaissance information.
• Establishes encrypted TCP-based command-and-control (C2) communication.
• Supports SOCKS5 proxy-based network tunneling.
• Dynamically loads external assemblies in memory using Assembly.Load.
• Executes arbitrary attacker-issued commands remotely.
• Provides file management functionality including upload, download, and deletion.
• Performs keylogging, screen capture, clipboard monitoring, and webcam/microphone surveillance.
• Sends periodic status and heartbeat updates to the C2 server.
• Uses encrypted and compressed network traffic to hinder analysis.
• Maintains persistence using Scheduled Tasks and Registry Run keys.
• Can add or remove itself from Windows startup locations.
• Operates covertly to maintain long-term unauthorized access.
• Includes self-uninstall and self-deletion functionality for cleanup after execution.

Infrastructural Artefacts & Threat actor Attributions:

Based on our analysis and Tracking history of this chain and TPPs with all those proofs we have attributed this Campaign under the cluster of SideCopy with Medium – High Confidence level as previous mentioned During infrastructure analysis, the delivery domain abimj[.]edu[.]af resolved to two IP addresses — 103.132.98.224 and 103.132.98.226 — both sitting within the 103.132.98.0/23 block attributed to AS58469, the Afghan Ministry of Communication and Information Technology.

Passive DNS pivoting across this IP block revealed over 200+ legitimate Afghan government and education domains co-hosted on the same infrastructure, confirming the threat actor deliberately staged their delivery layer inside Afghanistan’s own sovereign internet infrastructure — a calculated move to blend malicious traffic with legitimate government communications and evade network-level detection.

Pivoting further on the RAT’s C2 server 185.235.137.106 revealed a Windows host running HTTP, HTTPS, and a non-standard RDP port — consistent with an operator-managed dedicated C2 box.

The server is hosted on AS59711 (HZ Hosting Ltd), a Bulgaria-registered provider with Frankfurt physical presence, previously documented in SideCopy infrastructure reporting by Seqrite.

Three domain clusters resolved to this IP at the time of analysis, including actor-registered throwaway domains across .xyz, .live, and .online TLDs, alongside a fully configured mail infrastructure domain — indicating the same server was serving both RAT communications and phishing delivery operations simultaneously.

The attack chain — LNK executing mshta.exe to fetch a remote HTA via an index.php endpoint — is a signature SideCopy TTP documented consistently since 2019 and remains one of the group’s most reliable identifiers. The use of XenoRAT specifically strengthens this attribution, as Seqrite Labs confirmed in December 2024 that SideCopy had formally adopted customised XenoRAT variants as part of their updated toolset, following a similar pattern of open-source RAT adoption seen previously with AsyncRAT. Registry-based persistence through a Run key with a process name typosquatting a legitimate Windows application is equally consistent with documented SideCopy post-exploitation behaviour.

At the infrastructure level, the delivery domain was registered through AFGNIC and staged on the same IP block as legitimate Afghan government infrastructure — a deliberate blending technique consistent with SideCopy’s documented pattern. The RAT C2 on HZ Hosting (AS59711) further corroborates this, as the same provider has appeared in prior SideCopy infrastructure clusters tracked by Seqrite. Notably, the naming consistency between the delivery path (cloudiyaf) and the RAT’s hardcoded startup name (clouda) suggests a single operator managing both infrastructure tiers — tying the delivery and post-exploitation layers to the same actor.

Conclusion: Why Operation XENOFISCAL?

The name is derived directly from the two defining characteristics of this campaign — XenoRAT, the open-source remote access tool deployed as the final payload, and Fiscal, reflecting the precise targeting of Afghanistan’s Ministry of Finance provincial network. Together they form a single codename that captures both the weapon and the victim in one word. The threat actor’s deliberate choice to deploy a financially-themed lure against a finance ministry, combined with a RAT capable of silent long-term surveillance, made the pairing unavoidable. XENOFISCAL is not just a name — it is a summary of the entire operation in eight letters.

Seqrite Coverage:

• Downloader.50744.GC
• Netloader.50745.GC
• LoaderCiR
• YakbeexMSIL.ZZ4
• script.trojan.1779477414

IOCs:

MITRE ATT&CK:

The post Operation XENOFISCAL: SideCopy deploying persistent XenoRAT targeting the MoF, Afghanistan appeared first on Seqrite Labs.

Please leave this field empty

Oh hi there 👋
It’s nice to meet you.

Sign up to receive awesome content in your inbox, every month.

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.

Please leave this field empty

Oh hi there 👋
It’s nice to meet you.

Sign up to receive awesome content in your inbox, every month.

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.