Digital-marketing and paid-media professionals in Bangladesh are under sustained pressure from fake-recruitment social engineering. The approach commonly opens on LinkedIn, where a recruiter persona makes contact off the back of a public profile and job history, then moves to email once the target engages. By that point the exchange already resembles a live hiring process rather than a cold approach. In mid-August we obtained a sample of one such lure: an email sent in the name of Rebels Market, an alternative-fashion marketplace, congratulating the recipient on advancing past the first round for a marketing role, with two assessment tasks to be downloaded and returned within 24 to 48 hours.
The link went to Dropbox. The archive password was in the email body: rebelsmarket.
Publishing the password in the message body is a deliberate choice. A password-protected archive cannot be opened by the mail gateway, the cloud AV, or the sandbox that would otherwise detonate it. The recipient, reading the password in the same message, opens it without difficulty.
The archive contained a five-stage chain rather than a document. It unpacks a complete Python runtime and a Microsoft-signed kernel driver onto disk, then uses that driver to terminate security software from kernel mode.
The email reached us as body text only: no headers, no Received chain, no SPF or DKIM results, so we cannot confirm that the message itself authenticated. Whether the sending domain is attacker-controlled is a separate question, and one the DNS does answer; see the indicators below. Nor do we hold any record of how the recipient was first approached. The LinkedIn-first pattern described above is characteristic of this class of campaign, but for this case we can evidence the email and nothing before it. Everything else below comes from static analysis of the files themselves.
Stage 1: DLL Side-loading
The extracted folder holds a lure-named executable and two DLLs. All three matter, and only one of them is malicious.
RebelsMarket_Marketing_Strategy_Plan.exe is Microsoft Word, renamed. The export directory still names it winword.exe, it forwards DllGetLCID to MSO.DllGetLCID, and it carries a valid Authenticode signature under Microsoft Code Signing PCA with the MOPR organisational unit, valid 2013-01-24 to 2014-04-24. The binary itself is entirely legitimate.
The rename is driven by one line in its import table: winword.exe imports 23 functions from MSVCR100.dll, the Visual C++ 2010 runtime. Windows resolves that import by searching the application's own directory first, so a file named msvcr100.dll placed next to the executable is loaded in preference to the system copy.
The msvcr100.dll delivered in that folder is the malicious component of the set.
The third file, words.dll, is the genuine MSVCR100.dll: 1,591 exports, signed under Microsoft Root Authority, renamed to something neutral. The malicious proxy forwards every CRT call to it, so Word starts, runs and behaves normally while the attacker's code executes in DllMain.
Export Count Comparison
The most reliable detection primitive in the chain is an export count.
The genuine MSVC 2010 runtime exports 1,591 symbols. This proxy exports 1,592. The extra one is _cgo_stub_export at ordinal 443, an artifact of building a Go DLL in c-shared mode.
An msvcr100.dll with 1,592 exports is therefore malicious by construction, as is any msvcr100.dll with an export forwarding to words.dll. Neither test is heuristic: no benign build of the Microsoft CRT has either property.
File Bloating
The delivered msvcr100.dll is 157,286,891 bytes. The actual code is about 3.7 MB.
97.65% of the file is padding: 153,590,272 bytes of high-entropy filler appended at offset 0x3867eb and described by a 23rd section header named .pad. Shannon entropy across the region is 8.00000, and no two of the 2,344 blocks it divides into at 64 KiB are identical, so it is not a repeated pattern.
The purpose is scan evasion. Many AV engines, sandboxes and scanning pipelines skip files above a size threshold, so inflating a 3.7 MB DLL to 150 MB imposes no cost on the attacker and removes the file from consideration by a substantial amount of tooling. One consequence for detection engineering: scanner size limits must be raised, or a YARA rule written for this sample will never run.
A magic-byte scan and a per-block entropy scan across the padding found no hidden content. Both methods would miss a payload stored as high-entropy ciphertext with no magic bytes.
The bloater set .pad's PointerToRawData to the COFF PointerToSymbolTable (0x349000) rather than the true pre-bloat end of file. Cutting at the section pointer also destroys the COFF symbol table: 6,831 symbols, 2,735 of them Go package symbols, which is most of what makes this binary readable. The correct cut is 0x3867eb.
Stage 2: Encrypted Container (AppxMeta14)
Alongside the triad sits a file called AppxMeta14, 22.8 MB, with no recognisable header; it begins with random-looking bytes. The Go code decrypts it with a byte-wise, position-dependent cipher using four separate keys:
plain[i] = amKey4[i % 32] ^ amKey3[i % 16]
^ ((amKey1[i % 16] ^ cipher[i]) - amKey2[i % 16]) & 0xFFNote the moduli: amKey4 is 32 bytes and is indexed % 32, the other three are 16. A decrypt that treats it as a 16-byte key produces plaintext that is nearly correct and never validates.
The decryption is verified rather than assumed, because the loader checks it itself. The plaintext begins with the 7-byte magic AMETA14, which is the loader's own integrity check. A wrong key cannot produce it.
Out of the container come 137 files, and most of them are entirely legitimate: a complete CPython 3.14 runtime, written to C:\Users\Public\Project\Python. The malicious content is four files.
vcruntime.dll: not a DLL, and not a PE. 14,776 bytes of base64 that decode to 339 lines of Python.process.txt: a kill list, 2,031 entries, formatProcessName.exe|Vendor.plugins.dll: the real payload, encrypted under AES-256-GCM.challenge.docx: the decoy, opened for the victim so that the double-click produces a visible result.
The decoy is a genuine Word document with no macros: a pre-interview assignment for a paid-ads specialist, with a USD 4,000/month budget exercise. Its metadata gives no author to pivot on. Creator and last-modified-by are both Un-named, revision 1, created and modified at the same instant, which means the document was generated programmatically rather than written in Word. It does date the campaign build to 2026-07-07, matching the archive entry times and the on-disk timestamps of the loader.
Stage 3: VBS droppers and privilege elevation
Two further files never appear when the archive is unpacked, because they are not in it. elev.vbs and lpay.vbs are Go string literals inside the loader, written to C:\Windows\Temp\ at runtime. A container-only analysis never sees them.
elev.vbs is four lines and performs the elevation:
Set sh=CreateObject("Shell.Application")
sh.ShellExecute "<exe>","","<dir>","runas",1The runas verb does not bypass UAC; it invokes it. Windows shows the consent dialog, and the whole kernel-driver half of this chain (installing a service, loading a signed driver, terminating EDR from ring 0) is contingent on the victim clicking Yes.
This is the most fragile link in the chain and the most effective single point of intervention. The gate is not strong: a user who has already extracted a password-protected archive and run an executable is likely to approve a consent dialog that appears seconds later. It remains a genuine control point, and it supports one piece of user guidance: a job assignment should never require administrator rights.
Detection
The highest-fidelity single artifact in this half of the chain is a command line. When lpay.vbs runs, it produces:
pythonw.exe -c "import base64;exec(base64.b64decode(open(r'...vcruntime.dll','r').read()))"
A pythonw.exe that reads a file, base64-decodes it and hands the result to exec() is rare outside developer tooling. Combined with the path C:\Users\Public\Project\, which has no legitimate use, the expected false-positive rate is very low.
title: Python Interpreter Executing Base64-Decoded Script From Disk
id: 9d47b1c8-3a25-4e70-b8f6-0c519e2ad738
status: experimental
description: |
Detects pythonw.exe/python.exe invoked with an inline -c that reads a file,
base64-decodes it and passes the result to exec(). In the observed chain the
file is named vcruntime.dll but contains base64 Python source implementing
the BYOVD EDR killer, so the extension is a deliberate lie.
author: Shakil Hossain
date: 2026/08/14
tags:
- attack.defense-evasion
- attack.t1027
- attack.execution
- attack.t1059.006
- attack.t1140
logsource:
product: windows
category: process_creation
detection:
selection_python:
Image|endswith:
- '\pythonw.exe'
- '\python.exe'
selection_pattern:
CommandLine|contains|all:
- 'base64'
- 'exec('
- 'open('
selection_path:
CommandLine|contains:
- '\Users\Public\Project\'
- 'vcruntime.dll'
condition: selection_python and (selection_pattern or selection_path)
falsepositives:
- Developer tooling that bootstraps via inline base64. Should be rare and
attributable; the \Users\Public\Project\ path has no legitimate use.
level: criticalIt passes sigma check with zero errors, but it has not been fired against production telemetry, because we had none in this engagement. Treat the false-positive note as reasoned, not measured.
Two additional low-cost detections: wscript.exe or cscript.exe executing a .vbs staged directly in C:\Windows\Temp\; and any execution at all out of C:\Users\Public\Project\, a directory that should never appear on a clean host.
Indicators of Compromise
Indicators below are defanged. Hashes are not.
Email and Delivery
- Sender:
hr[@]rebelsmarket[.]de - Sender domain
rebelsmarket[.]deis attacker-controlled infrastructure, not a forged From line. It runs on Cloudflare nameservers with MX atmx1.titan.email/mx2.titan.emailandv=spf1 include:spf.titan.email ~all, with no DMARC record. The genuine brand isrebelsmarket[.]comon Shopify, Linode DNS and Google Workspace, sharing no infrastructure with it. Lookups performed 2026-08-16 - Subject:
Application for Marketing Specialist - Delivery URL:
hxxps://www.dropbox[.]com/scl/fi/frnv5x3n4lluq2wwpoou6/RebelsMarket_Marketing_Overview_Jul_27_13EK8R.rar?rlkey=z3wc6nvcf7t73hfnqjfr8a1t1&dl=1 - Dropbox file id
frnv5x3n4lluq2wwpoou6, sharing keyz3wc6nvcf7t73hfnqjfr8a1t1. These are the indicators, not the Dropbox domain - Archive:
RebelsMarket_Marketing_Overview_Jul_27_13EK8R.rar, passwordrebelsmarket
The LinkedIn, Facebook and Instagram links in the email footer point at the genuine company's real profiles. They are part of the impersonation, not indicators. Do not block them.
Files
- Stage 0, renamed winword.exe:
1260eed47c7e8200b78673397274e859bd1a3a7abe6ec8c6880dbe5fdccfe068(1,924,768 bytes) - Genuine CRT, renamed words.dll:
ae3cb6c6afba9a4aa5c85f66023c35338ca579b30326dd02918f9d55259503d5(829,264 bytes) - Stage 1 msvcr100.dll as delivered:
dfb652186259b35059c42f318df1c81fb2d1798b250e8c171dc44fde3874d0e1(157,286,891 bytes) · MD57d1d06b4f52fc9e29404dc2778c4e55d - Stage 1 debloated, lossless:
e699b144016a90c75371b8162c9ad3cff0f61c1aaadb8edb857acd3b630c6ea4(3,696,619 bytes). This is an analysis artifact we produced, not a file that exists on a victim host. Do not add it to a blocklist - AppxMeta14 container:
380687b6b848cf231d15e000317bece8391d380095f578b09929ec463fcc4db6(22,793,556 bytes)
Host Artifacts
C:\Users\Public\Project\Python\
C:\Users\Public\Project\Python\pythonw.exe
C:\Users\Public\Project\Python\msvcr100.dll
C:\Users\Public\Project\Python\AppxMeta14
C:\Users\Public\Project\Python\vcruntime.dll
C:\Users\Public\Project\Python\plugins.dll
C:\Users\Public\Project\Python\process.txt
C:\Users\Public\Project\Python\challenge.docx
C:\Windows\Temp\elev.vbs
C:\Windows\Temp\lpay.vbsStatic anchors: the AMETA14 container magic; the four amKey byte strings; a PE carrying a .pad section whose SizeOfRawData exceeds 100 MB at entropy above 7.99. One caveat applies to the first of those anchors: as delivered, AppxMeta14 is fully encrypted and has no plaintext magic at all, so AMETA14 matches the decrypted container only. Deployed as a file-scanning rule against samples on disk, it provides no coverage and reports no error.
The next post picks up at vcruntime.dll: the base64 Python that installs a legitimately signed, publicly catalogued vulnerable driver and uses it to terminate security software from kernel mode.