JitterDropper

Pure Facts (Who, What, When, Where):
Who: The JitterDropper dropper is a Rust/MSVC Windows dropper with the ability to perform anti-analysis and decrypt or download second-stage shellcode through VirtualAlloc -> VirtualProtect.
What: It embeds payload in .rdata, downloads from pixeldrain[.]com, uses specific sleep-jitter budgets for different APIs, and implements a fixed Lemire reduction on milliseconds conversion before sleeps.
When: Observations started since 2026-03-18, with nine builds identified across two lines of development. Recent observed builds include 9957bf9bc95be77c (Variant II) and e8082e3c0d63f83ad95af88f50e9ae26 (Variant I).
Where: The dropper uses Rust 1.92.0 MSVC toolchain compiled with ded5c06cf21d2b93bffd5d884aa6e96934ee4234, embedded and decrypted in .rdata.

Facts Only:
JitterDropper is a new Rust/MSVC Windows dropper observed since March 18th, 2026.
Nine builds across two variant lines were identified starting from March 18th with the name unknown but called "JitterDropper".
Uses sleep-jitter budgets: 60 ms before InternetOpenA, 150 ms before StringFromGUID2, 100 ms before CoGetObject, and 120 ms before CoUninitialize across all builds.
Rust compiler version is rustc/ded5c06cf21d2b93bffd5d884aa6e96934ee4234 on the same toolchain (rustc).
All samples are compiled against a consistent Rust 1.92.0 MSVC toolchain.
Contains 32 bytes that rustc emits for Duration::frommillis(variable), followed by specific Lemire reduction and imul edx, eax, 0xF4240 to convert milliseconds to nanoseconds before sleeps.
Stagers use varying sleep-jitter budgets depending on API calls: InternetOpenA at 60 ms, StringFromGUID2 at 150 ms, CoGetObject at 100 ms, and CoUninitialize at 120 ms for all builds except the regressed build (99789e9bc95be77c).
Stagers are compiled against different APIs: Variant II stager is compiled against Rust's standard library, VCRUNTIME140.dll, and is built as a GUI executable with no message pump.
Anti-analysis features include:
Inline anti-debug check (CheckRemoteDebuggerPresent -> IsDebuggerPresent)
Randomised class/title strings in the cover window
Stalls on 21–27 iterations of EnumWindows to prevent wall-clock time compression and gate at each checkpoint with GetTickCount, randomised Sleep, and elapsed-check gates.
The stagers use W^X memory protection except for the regressed build which allocates RWX directly.
The jitter-budget-per-API fingerprint is unique to JitterDropper and includes specific sleep-jitter values that are unchanged across every build where that API appears.

<ROOT CAUSE>
The narrative of JitterDropper is driven by the author's strategic choices in implementing sleep-jitter budgets for different APIs. The use of these particular sleep values (60 ms, 150 ms, 100 ms, and 120 ms) appears to be tied directly back to the developer. This specific implementation strategy seems to have no other plausible explanation outside this single instance.
The per-API divisor table mentioned in Table 1 is what distinguishes JitterDropper from compiler-output coincidences. The Lemire reduction (000 000/1000) used for converting milliseconds to nanoseconds before sleeps is also present across unrelated Rust programs, making it a general feature of Rust compilation rather than unique to this dropper.
The introduction of AES-256-GCM wrapping on the second-stage shellcode by Variant II appears as a significant evolution in the dropper's functionality. The addition of dynamic resolution for BCrypt and an injection into explorer.exe suggests that the team involved was looking to enhance or diversify their dropper's capabilities, possibly as part of a broader security initiative.
The regression from RWX memory protection (on 2026-04-11) indicates that there may have been a branch off the main tree at some point in the development timeline. The introduction of AES-256-GCM on a fork suggests another fork was introduced, likely to focus on different security features.
The use of sleep-jitter values specific to each API with fixed divisors (e.g., 100 ms for CoGetObject) is highly indicative of deliberate strategy rather than mere coincidence. This type of implementation detail lends strong support to the argument that JitterDropper is a purposefully created dropper.