May 14, 2026 12 min read

From PyInstaller to XWorm V7.4: Infection Chain Analysis

Kedar Shashikant Pandit, Prathamesh Shingare, and Amol Swami Lat61 Threat Intelligence Team
From PyInstaller to XWorm V7.4: Infection Chain Analysis

Executive Summary

Point Wild conducted an in-depth analysis of a suspicious PyInstaller-packed Python sample and identified it as a multi-stage malware loader designed to deploy the XWorm Remote Access Trojan (RAT), specifically associated with the XWorm V7.4 campaign. The sample leveraged multiple layers of obfuscation, staged execution and anti-analysis techniques to conceal its true functionality and evade detection by traditional security controls.

  • During the investigation, the extracted .pyc component (BA4Q6ACPMNrd980FwZn9iEbEqkjvRmw7FhW.pyc) revealed a structured execution chain in which an initial decoy routine (_IAT_PHANTOM_FIX) acted as anti-analysis filler code, while the primary malicious activity was performed through the _VOID_DEPLOYER function. The malware demonstrated advanced defense-evasion behavior by performing in-memory patching of AmsiScanBuffer to weaken Microsoft AMSI-based inspection and reduce AV/EDR visibility prior to payload deployment.
  • Further analysis confirmed that the loader decrypts and decompresses an embedded executable payload directly from the Python package, writes the payload into the %LOCALAPPDATA% directory, modifies file attributes to Hidden and System for stealth and executes the payload silently in detached mode without displaying a visible console window.
  • The deployed payload was identified as XWorm V7.4, a known RAT capable of enabling unauthorized remote access, command execution, credential theft, surveillance activities and secondary payload delivery on compromised systems. Network analysis additionally identified outbound communication attempts toward the command-and-control (C2) infrastructure at tcp://68[.]219[.]64[.]89:4444, confirming remote attacker-controlled functionality.
  • The overall infection chain demonstrates characteristics commonly associated with modern malware delivery frameworks, including PyInstaller-based packaging, multi-stage payload deployment, AMSI bypass mechanisms, payload obfuscation and stealth-oriented execution techniques. Based on the observed capabilities and behavioral indicators, Point Wild assesses this sample as a high-confidence malicious loader/dropper responsible for deploying XWorm RAT infrastructure and enabling persistent unauthorized access within targeted environments.

So, the question arises: how does this malware operate internally, and what evasion techniques does it leverage to bypass traditional defenses?

At Point Wild, we help uncover and analyze stealth-focused threats designed to evade conventional security inspection. By identifying suspicious execution flows, obfuscated payload delivery mechanisms, and defense-evasion techniques such as AMSI patching and staged malware deployment, Point Wild UltraAV helps improve visibility into advanced threats before full payload execution and system compromise occur.

Possible Initial Infection Vectors

  • Phishing email attachments containing malicious executables or archives
  • Supply Chain: Software Compromise
  • Trojanized applications disguised as legitimate software
  • Malicious downloads from suspicious or compromised websites
  • Fake software updates or installer packages
  • Social engineering campaigns tricking users into manual execution
  • Compressed archive files (.zip, .rar) containing the PyInstaller-packed malware
  • Shared executable files distributed through messaging platforms or forums
  • Bundled malware distributed alongside freeware or unofficial tools
  • Malvertising campaigns redirecting users to malware-hosting pages

Attack Flow

Fig 1: Attack Flow

Stage 1: Analysis of Python Installer Packed executable

Fig 2: File InfoInitial analysis of the sample using “Detect It Easy” revealed strong indicators of PyInstaller-based packaging, specifically flagged as “PyInstaller [modified]”, suggesting the executable was generated from a Python application and potentially altered to hinder conventional unpacking or static inspection. The presence of a modified PyInstaller stub is commonly observed in modern malware campaigns.

PyInstaller Extraction:

Following extraction of the PyInstaller package, the executable unpacked into multiple embedded Python runtime components, compiled Python bytecode files (.pyc), dynamic libraries and compressed archive resources commonly associated with PyInstaller-based applications.

Fig 3: Extracted files from PyInstaller

Among the extracted components, a suspicious compiled Python bytecode file named:

BA4Q6ACPMNrd980FwZn9iEbEqkjvRmw7FhW.pyc

was identified as the primary malicious module within the package. The randomized filename structure appears intentionally generated to hinder quick identification and complicate manual analysis efforts.

Decompiled Code analysis of BA4Q6ACPMNrd980FwZn9iEbEqkjvRmw7FhW.pyc

Phase 1: Runtime Initialization & API Resolution:

Fig 4: API resolution

After execution begins, the loader initializes access to low-level Windows APIs through the ctypes interface.

Instead of statically importing sensitive APIs, the malware reconstructs API names dynamically using character-shifting logic:

''.join([chr(ord(c) - 1) for c in ...])

The reconstructed strings are then resolved through:

k32.GetProcAddress(k32.LoadLibraryA(...))

This phase serves multiple purposes:

  • Conceal sensitive API names,
  • Reduce static signature visibility,
  • Avoid suspicious plaintext imports,
  • Dynamically prepare memory manipulation routines.

The resolved API ultimately targets AMSI-related functionality.

Phase 2: AMSI Memory Patching

Once the required API addresses are resolved, the loader performs direct in-memory modification of the AMSI scanning interface.

Fig 5: AMSI memory patching

The malware changes memory protection permissions using:

VirtualProtect(addr, len(p), 64, ctypes.byref(o))

It then overwrites the target memory region with custom patch bytes:

ctypes.memmove(addr, bytes(p), len(p))

Observed patch bytes:

[184, 87, 0, 7, 128, 195]

This stage is specifically designed to interfere with AMSI scanning functionality before payload reconstruction begins.

By modifying executable memory regions at runtime, the malware attempts to:

  • Weaken AMSI inspection,
  • Reduce AV/EDR visibility,
  • Bypass script scanning,
  • Lower the probability of payload interception.

This behavior is commonly associated with staged loaders and obfuscated malware frameworks attempting to execute embedded payloads without triggering runtime inspection mechanisms.

Phase 3: Embedded Payload Decoding & Decryption

After AMSI modification is completed, the malware begins reconstructing the embedded payload.

The loader first decodes the embedded blob using:

raw = base64.b85decode(d_e)

A SHA-512-derived key is then generated from the supplied parameter:

mk = hashlib.sha512(k_s.encode()).digest()

The malware subsequently processes the decoded blob through a custom transformation loop involving:

  • Rolling state calculations,
  • XOR operations,
  • Modular arithmetic,
  • Byte rotation logic.

Core transformation logic observed:

Fig 6: Payload decoding & decryption

This phase functions as a layered obfuscation and decryption mechanism intended to:

  • Conceal the embedded executable,
  • Prevent direct payload extraction,
  • Disrupt static analysis,
  • Increase reverse engineering complexity.

Rather than storing the payload as a visible executable resource, the malware reconstructs it dynamically during execution.

Phase 4: Payload Reconstruction & Decompression

Once the transformation loop completes, the reconstructed byte stream is decompressed using:

dec = zlib.decompress(p_l)

This restores the original embedded executable payload in memory.

The use of compressed payload storage helps:

  • Reduce recognizable PE artifacts,
  • Increase entropy,
  • Conceal embedded structures,
  • Reduce the effectiveness of static detection mechanisms.

The malware additionally appends randomized junk data before deployment:

Fig 7: Payload reconstruction with decompressed

Appending random bytes likely serves to:

  • Alter final file hashes,
  • Disrupt signature consistency,
  • Complicated hash-based detections across samples.

Phase 5: Stealth-Oriented Payload Deployment

After reconstruction completes, the malware prepares the payload for deployment within the local user environment.

Fig 8: Payload deployment

Deployment path observed:

%LOCALAPPDATA%\Win.Kernel_Svc_AJ8iOw.exe

Fig 9: Drop File

The filename intentionally imitates legitimate Windows service naming conventions to reduce suspicion.

The payload is written using:

with open(_fp, ‘wb’) as f:

f.write(_f_bin)

This deployment phase avoids temporary extraction locations and directly stages the payload into a user-accessible application directory.

Phase 6: Hidden & System Attribute Manipulation

Following deployment, the malware modifies file attributes through:

Fig 10: File attribute sets

The value 8198 corresponds to:

  • FILE_ATTRIBUTE_HIDDEN
  • FILE_ATTRIBUTE_SYSTEM

This phase reduces visibility of the deployed payload during normal filesystem browsing and supports stealth-focused execution.

Phase 7: Detached Background Execution

In the final stage, the malware launches the deployed executable through:

Fig 11: Background execution with suppress visible console creation

The specified creation flags suppress visible console creation and allow silent background execution.

This execution technique:

  • Minimizes visible indicators to the user,
  • Reduces execution visibility,
  • Enables uninterrupted payload operation.

Phase 8: Anti-Analysis Decoy Execution

Before the main deployment chain begins, the malware invokes:

_IAT_PHANTOM_FIX()

This routine repeatedly generates SHA-512 hashes:

[hashlib.sha512(str(i).encode()).hexdigest() for i in range(1000)]

Fig 12: Anti analysis decoy image

The function does not directly participate in payload deployment and instead appears intended to:

  • Generate execution noise,
  • Consume analysis time,
  • Complicate behavioral tracing,
  • Mislead superficial inspection efforts.

Encoded Data Blob passed to DEPLOYER routine

Fig 13: Encoded data blob

The embedded blob contains high-entropy encoded content with randomized character distribution, strongly indicating layered obfuscation and encrypted payload storage. No readable PE structures or recognizable executable signatures are directly visible within the blob.

Decrypted Payload

After passing through all above phases the decoded payload is identified as afacan313131.exe using CFF explorer which is .Net Assembly.

Fig 14: File Info of decrypted payload

Stage 2: Analysis of afacan313131.exe

Technical Analysis:

During our analysis, we identified a .NET assembly routine using AES-based runtime decryption to hide configuration data such as C2 details, ports and keys for preventing static extraction also a mutex is implemented to ensure single-instance execution, while system sleep is disabled to maintain persistence.

Xworm Configuration:

From below images we get xworm’s embedded configuration, which includes the Xworm_Version identifier, hardcoded C2 server address ,C2 port and AES secret key. All subsequent C2 communications leverage TCP with AES-ECB encryption.

Fig 15: AES-based runtime decryption of C2 server

The below images shows that this worm belongs to 7.4 version including its AES secret key “<V74PV74PV74PV74PV74P>” and C2 port “4444”.

Fig 16: Decrypted Xworm version- 7.4

Fig 17: Decrypted AES Secret key

Fig 18: Decrypted C2 Port

After this extraction, the file connects to the TCP host (C2) using the ConnectServer method. It initializes an asynchronous socket connection to a remote server, transmits host reconnaissance information and maintains communication using periodic heartbeat timers. The implementation uses dynamic packet buffering and randomized beacon intervals, indicating an attempt to evade network-based detection and support long-term remote tasking capabilities.

Fig 19: C2 connection routine

System Profiling and Reconnaissance

Fig 20: System reconnaissance and profiling routine

XWorm performs extensive host reconnaissance prior to C2 connection, collecting:

  • Execution timestamp (file drop tracking)
  • Privilege escalation status (UAC validation)
  • Webcam enumeration (surveillance capability assessment)
  • Hardware specifications (CPU/GPU/RAM via WMI)
  • Security product inventory (AntivirusProduct WMI class)

Fig 21: Collecting Victim Info

Xworm generating Victim ID and concatenating them with victim info

Fig 22: Generating Victim ID

The extracted victim info is concatenated into a string and sent to the C2 server along with Client ID. Client ID is generated using ProcessorCount, UserName, MachineName and OSVersion. Generates a unique client ID for each victim, enabling the attacker to identify stealthily compromised machines and issue targeted command-and-control instructions.

Xworm Command and control sets

Fig 23: C2 Instruction sets

This image shows that the code segment implements the malware’s primary encrypted command dispatcher responsible for processing tasking instructions received from the command-and-control server. Incoming packets are AES-decrypted, delimiter-parsed, and routed to specific operational handlers supporting heartbeat communication, malware restart, self-removal, self-update, disk-based payload deployment and fileless in-memory execution. The presence of reflective memory execution, compressed payload staging and encrypted C2 communication demonstrates a modular and stealth-oriented malware architecture designed for long-term remote operations and dynamic capability delivery.

Fig 24: C2 controlled payload execution & DDos operation

This image shows that the segment implements several high-risk post-compromise capabilities including remote payload delivery, arbitrary shell execution, URL launching, system power control and distributed denial-of-service (DDoS) orchestration. Xworm downloads attacker-controlled payloads into the temporary directory using randomized filenames before executing them directly via Process.Start(). Additionally, it provides hidden command execution through Interaction.Shell(), granting operators full remote administrative control over the infected system. The threaded DDoS implementation further indicates botnet functionality, enabling compromised hosts to participate in coordinated network flooding attacks under centralized command-and-control supervision.

Xworm Plugin

Fig 25: Dynamic invocation via reflection

This image shows that the code dynamically identifies and invokes the Run method of a reflected plugin assembly using .NET late binding and reflection. The malware passes operational parameters—including the active command-and-control host, communication port, packet delimiter, encryption key, and victim identifier—to the plugin, enabling autonomous execution of attacker-supplied capabilities. The reflective invocation mechanism supports modular, fileless in-memory execution and significantly enhances the malware’s extensibility and stealth characteristics.

Techniques & TTPs

Tactic Technique ID Technique Name Mapped Activity
Execution T1059.006 Command and Scripting Interpreter: Python Core malicious logic written in python, compiled to .pyc bytecode and packed via PyInstaller
Persistence T1543 Create or Modify System Process Payload deployed to %LOCALAPPDATA%\Win.Kernel_Svc_AJ8iOw.exe mimicking as a windows service name
Defense Evasion T1685.001 Disable or Modify Tools In memory patching of AmsiScanBuffer using VirtualProtect with custom patch byte
Defense Evasion T1140 Deobfuscate/Decode Files or Information Runtime decoding using SHA-512 derived key & decryption loop with decompress to reconstruct the payload
Collection T1005 Data from Local System Credential theft and data collection capabilities documented as part of Xworm RAT feature
Command and Control T1095 Non-Application Layer Protocol TCP socket connection to C2 server using async socket with heartbeat timers
Execution (Plugin/Reflection) T1620 Reflective Code Loading .Net reflective used to dynamically invoke plugin assembly Run method for fileless in memory execution with attacker supplied capabilities

Detection and Mitigation

UltraAV, powered by Point Wild, helps defend against such threats by focusing on initial-stage files received from various sources including abused GitHub Pages, compromised websites, Social engineering campaigns and trojanized applications disguised as legitimate software installed by users.

Fig 26: UltraAV detection

As threats like Xworm continue to rise, so does the need for robust antivirus software. Whether you’re working, gaming or shopping, let UltraAV safeguard your digital life. Download UltraAV now and stay safe from malware, viruses and emerging threats like Xworm.

Conclusion

Point Wild’s analysis of the recent XWorm V7.4 campaign highlights how attackers are abusing PyInstaller to distribute malware through packaged applications. By identifying and analyzing these emerging delivery techniques, Point Wild helps organizations stay aware of evolving cyber threats and improve their ability to detect suspicious files before they impact users or business operations. This research demonstrates Point Wild’s proactive threat research capabilities and commitment to helping customers stay protected against modern malware campaigns.

Indicators of Compromise

MD5 Description
c7a6f220f2ff7d6718a5b2f0e85f13dd PyInstaller Executable
d4494a5b1430f7c5347408732cdbd668 %LOCALAPPDATA%Win.Kernel_Svc_AJ8iOw.exe(afacan313131.exe)
tcp://68[.]219[.]64[.]89:4444/ C2 Server

Additional Resources

XWorm Malware Analysis Report

Keep reading