RFQ Malware Campaign Uses DOCX, RTF, JS, and Python

Hackers are abusing DOCX, RTF, JavaScript, PowerShell, and Python to deliver an in‑memory Cobalt Strike beacon in a stealthy spear‑phishing campaign that impersonates Boeing procurement under the tag NKFZ5966PURCHASE.

The operation chains six stages, relies heavily on living‑off‑the‑land binaries, and reuses the same encryption keys across all known samples, creating both strong evasion and clear opportunities for defenders.

The attached documents use rotating filenames such as “Rfq and Payment Schedule.docx,” “Product_specifications.docx,” and “RFQ_PO_ATR29026II.docx,” but share identical metadata and document structure.

Across all variants, the creator is listed as “Christian Booc” and the last modifier as “John,” with a template created in 2021 and weaponized in early 2026, indicating reuse of an older RFQ template without sanitizing author fields.

Acoording to the report, The campaign begins with targeted RFQ‑themed emails spoofing “Joyce Malave from Boeing” or “Global Services, LLC,” sent to procurement and sales teams, promising high‑volume orders and “best prices.”

NKFZ5966PURCHASE tag links at least 22 artifacts spanning the full chain, including DOCX and RTF lures, JavaScript droppers, ZIP payloads, and Cobalt Strike components, with submissions clustered around March 31–April 1, 2026, and reported by researchers such as JAMESWT_WT.

The volume and timing suggest an active campaign still in development, with operators iterating on lures while preserving a stable backend architecture and cryptographic configuration.

RFQ Malware Campaign

Opening the DOCX reveals a standard OOXML ZIP container, but the relationships file abuses Word’s aFChunk feature to embed and render an RTF as part of the document, effectively hiding the real payload behind a normal‑looking RFQ.

The embedded RTF files (for example rsuas.rtf or similar names) are unusually large, around several megabytes, because they carry hex‑encoded content inside the {*\svb} destination group that Word parses but does not display.

That hex blob decodes to another OOXML structure wrapping an OLE object, which in turn contains obfuscated JavaScript that becomes Stage 2 of the chain.

This aFChunk‑plus‑RTF layering is not new, but it remains under‑inspected by many email gateways that stop at high‑level DOCX parsing and do not recursively walk alternative format chunks.

YARA rules like FreddyBearDropper show that researchers are tracking similar embedded‑RTF‑to‑script techniques, though these detections are not yet broadly deployed in enterprise products.

From the OLE object, analysts recovered multiple JavaScript droppers (for example “license.js” and variants) that store their logic as a single string split by a junk separator, which is removed at runtime to reconstruct the code.

Once deobfuscated, the scripts use WMI’s Win32_Process via wscript to spawn the next stage silently, avoiding obvious command windows or UI artifacts on the victim workstation.

The JavaScript launches PowerShell with a Base64‑encoded command that implements a downloader with several evasion tactics, including disabling TLS certificate validation through a custom TrustAllCertsPolicy class and invoking network APIs indirectly to frustrate AMSI‑based detections.

Network requests masquerade as Chrome traffic, add a file‑sharing referer, and pull a roughly 14.5 MB ZIP from Filemail.com subdomains such as 2007.filemail.com and 2117.filemail.com, a reputable Norwegian file‑sharing service not typically blocked by URL filters.

At least one of these URLs remained live at last check, still serving the ZIP under a misleading “.mp3” filename via the Content‑Disposition header while delivering a Python payload.

Python Runtime Loader

Once downloaded, the ZIP is unpacked into the user’s roaming profile and reveals a full Python 3.12 x64 runtime, including a signed pythonw.exe, PyCryptodome, and several helper scripts such as Protected.py and builtin.py alongside a faux “license.pdf” file.

That so‑called PDF is actually an encrypted DLL blob; it is never opened by a PDF viewer but only accessed programmatically by the Python loader, allowing it to bypass basic document inspection.

Protected.py implements a multi‑layer obfuscation pipeline (Base64, compression, byte reversal, ROT13, and XOR) before using AES‑256‑CBC and additional XOR operations to decrypt the DLL and load it reflectively into memory.

All analyzed samples reuse the same AES key, IV, and XOR keys, which is a major operational security failure because a single key leak enables decryption of every past and future payload that keeps this configuration.

Memory analysis of similar chains in other Cobalt Strike incidents shows reflectively loaded DLLs, anti‑debug logic, and PE images without import tables, matching what defenders expect from mature beacon deployments.

For persistence, the malware adds a Run key named “RtkAudUService” under HKCU, mimicking a Realtek audio component commonly present on Windows systems.

Instead of calling pythonw.exe directly, it abuses SyncAppvPublishingServer.vbs, a signed Microsoft script used as a living‑off‑the‑land binary, to launch PowerShell, which in turn starts pythonw.exe with the malicious loader, stacking multiple trusted components between the autorun entry and the final payload.

Despite its sophistication, the campaign exposes several defensive footholds: unsanitized document metadata, a five‑year‑old RFQ template reused across lures, a stable NKFZ5966PURCHASE tag across MalwareBazaar submissions, hardcoded static encryption keys, and repeated use of Filemail infrastructure.

Defenders should add detection for DOCX aFChunk‑embedded RTF content, inspect large RTFs with hidden data, monitor for unusual Python runtimes in user profiles, and hunt for suspicious Realtek‑like Run keys chained to SyncAppvPublishingServer.vbs on endpoints.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.