PackXOR Unpacked: Inside FIN7's Private Packer Used to Conceal AvNeutralizer and Other Payloads

Researchers at HarfangLab published a thorough technical analysis of "PackXOR" — a private packer used to conceal FIN7's AvNeutralizer anti-EDR tool — along with a public unpacking tool. The analysis also uncovered evidence that PackXOR is used to protect payloads unrelated to FIN7, raising questions about whether the packer is shared with or sold to other threat actors beyond the FIN7 cluster.

AvNeutralizer and the FIN7 Connection

AvNeutralizer (also tracked as AuKill) is a BYOVD-based anti-EDR tool that exploits vulnerable kernel drivers to terminate EDR-related processes from kernel mode. According to SentinelOne researchers, AvNeutralizer has been sold since 2022 on underground forums including xss[.]is, exploit[.]in, and RAMP by individuals assessed with high confidence to be part of the FIN7 cluster. Since April 2023, the tool has been delivered to targets as a packed or unprotected payload as part of ransomware operations by multiple threat actors. SentinelOne noted that the packer code was identical across all observed usages — suggesting FIN7 provides PackXOR as a shared obfuscator bundled with AvNeutralizer purchases.

HarfangLab's findings add a complication: PackXOR was also identified protecting XMRig cryptominer payloads and XMRig combined with the R77 rootkit, with an additional obfuscation layer from the open-source SilentCryptoMiner. Cryptomining activity does not fit known FIN7 TTPs, and the use of a secondary obfuscator on top of PackXOR makes it inconsistent with simple detection-evasion testing. HarfangLab assesses with medium-to-high confidence that PackXOR's developers may be connected to FIN7, but that the packer is being used for activities outside FIN7 operations.

PackXOR Technical Architecture

Packed data produced by PackXOR is structured around a 40-byte header stored at the beginning of the PE .data section, containing two XOR keys and size fields for both the compressed and uncompressed payload. The unpacking sequence proceeds through three steps: a first XOR pass using XOR key 1 is applied to the LZNT1-compressed data; the LZNT1 data is then decompressed via Windows' RtlDecompressBuffer; and a second XOR pass using XOR key 2 is applied to the decompressed output before the payload executes. This dual-XOR-plus-compression design means static signatures must account for both XOR keys, which change per sample, significantly raising the cost of signature-based detection.

String Encryption: Per-Blob XOR with Position-Indexed Subtraction

PackXOR uses run-time dynamic linking for sensitive Windows API calls, concealing the required DLL and function names as encrypted strings resolved just before use. Each string is stored in a structured data blob: the first byte is the per-string XOR key, the second byte is the string length, three bytes are unused padding, and the remaining bytes are the encrypted string content. The decryption algorithm XORs each byte with the blob's key, then subtracts the byte's position index (minus one) from the result. Critically, the XOR key differs for nearly every string within a sample and changes entirely across samples — maximizing resistance to static analysis by ensuring no two strings share a recoverable pattern, and no two samples produce identical encrypted representations of the same API name.

Broader PackXOR Usage and Defender Implications

HarfangLab identified four payload families beyond AvNeutralizer packed with PackXOR, including multiple samples delivering XMRig alone or combined with R77, with some wrapped in an additional SilentCryptoMiner obfuscation layer before PackXOR is applied. The identical unpacking code across all samples provides a reliable detection anchor regardless of the final payload — meaning defenders can detect PackXOR-protected binaries before the inner payload is known. HarfangLab has released a public unpacking tool to assist analysts in recovering payloads from PackXOR-protected binaries, and the analysis of its internal structure provides YARA-ruleable artifacts in the decryption stub, header layout, and string blob format that remain stable across the samples observed.

Read the full analysis on IntelFusions