Gamaredon Hides Credential-Stealer in Trojanized Driver Utility
A 39 MB installer impersonating the Easeware DriverEasy utility is delivering Dotfuscator-obfuscated .NET implants to construction-sector targets. CTX Team attributes the campaign to Gamaredon Group, citing a Babadeda-crypted dropper, timestamp forgery, and active sandbox-defeat logic stacked across every phase of the kill chain.
A Trojanized Driver Utility and a Three-Layer Evasion Stack
A 39-megabyte Windows installer masquerading as the legitimate Easeware DriverEasy driver-update utility is circulating with a forged compile timestamp, a near-maximum-entropy resource section concealing an encrypted payload, and two Dotfuscator-obfuscated .NET implant components built in the same toolchain session — a layered evasion architecture that CTX Team has attributed to Gamaredon Group and linked to construction-sector targeting. The campaign combines cracked-software distribution, Babadeda crypter staging, debugger detection, and what the available evidence suggests is credential-capture functionality, all wrapped in convincing Easeware product metadata that none of the three characterised files back with a valid code-signing certificate.
The tradecraft signal that makes this cluster analytically distinctive is not any single technique but the deliberate stacking of evasion layers across every phase of the kill chain: timestamp forgery at the dropper level, commercial .NET obfuscation at the implant level, and active sandbox-defeat logic at both. The result is a package that presents a plausible software identity to a casual user while resisting static and dynamic analysis at each stage.
The Masquerade: Unsigned Easeware Branding Across Three Components
All three characterised samples carry Easeware DriverEasy product metadata — meaningful filenames (DriverEasy_Setup.exe, DriverEasy.exe, Easeware.Driver.Core.dll), copyright strings reading "Copyright © 2025, Easeware. All right reserved.", and file version numbers consistent with a real DriverEasy release — while remaining entirely unsigned. The deliberate impersonation of a legitimate driver-update utility without a valid code-signing certificate is the campaign's primary social-engineering lever [T1036.005]: a user who sees a convincing product name, a plausible version string, and an installer of the size one would expect from a bundled driver package has little immediate reason for suspicion.
The dropper, SHA256 5b03e6e748863dcae92b13528ab969735c93b63b2cbcc97c5b57300ae74ce711, presents as DriverEasy_Setup.exe with internal name "Easeware DriverEasy 7" and file version 7.1.1.3510. The main implant executable, 19a7262e3f6f3499913849ab5b30fe038533dbcb4492e25eb5ad2610c79a68d0, presents as DriverEasy.exe version 7.1.0, while the companion DLL, 6135b4588ea0265d17f68382906d5b5ac2dcfd7dbab499e1528ac9244837e133, presents as Easeware.Driver.Core.dll version 7.1.0.0. Across all three, signed=false is confirmed in the dossier signing blocks — the Easeware brand is borrowed wholesale, but the operator either could not obtain or chose not to use a legitimate or fraudulently acquired code-signing certificate.
The absence of a signature is itself a tradecraft choice. Gamaredon Group, as attributed in the structured input, operates with an espionage motivation and has historically prioritised operational tempo over infrastructure polish. An unsigned but convincingly branded installer distributed through channels where users are already expecting to bypass normal software-distribution controls — pirated or cracked-software repositories — does not need a certificate to pass the social-engineering threshold. The target has already accepted elevated risk by seeking the utility outside official channels.
The submission path metadata for the main EXE (19a7262e) reinforces this picture. Among its recorded alt-names are paths consistent with portable application bundles and Chinese-language directory structures: G:\\????? (2)\\??????Driver Easy????\\????????????driver_easy_7.1.0.2641-Portable\\????????????DriverEasy\\App\\DriverEasy\\DriverEasy.exe. This suggests the trojanized package has been distributed as a portable bundle through file-sharing ecosystems, not merely as a standalone installer — widening the potential victim pool beyond whoever directly ran the dropper.
The Dropper: Babadeda Crypter, Timestamp Forgery, and a 39 MB Payload Cavity
The outer layer of the attack chain is the Babadeda-crypted dropper 5b03e6e7, a 39 MB PE32 GUI executable that carries the most analytically striking anomaly in the dataset: a PE compile timestamp of 2019-07-30 sitting six years before the file's own copyright claim of 2025. This is not a compiler artefact or an inherited timestamp from a reused build environment — it is deliberate timestamp forgery, a technique designed to mislead triage analysts who use compile-time as a rough indicator of when a sample was built and whether it is contemporaneous with a known campaign window.
The forgery is exposed by the internal contradiction: no legitimate software vendor ships a 2025-copyrighted product compiled in 2019. The dropper was first submitted to VirusTotal on 2026-04-16, placing its active deployment well after both the forged timestamp and the copyright year, and confirming it as a recently active component rather than a legacy artefact.
The payload concealment mechanism is the .rsrc section, which registers an entropy of 8.0 — effectively the theoretical maximum for compressed or encrypted data — and occupies 39,876,608 bytes, accounting for nearly the entire 39 MB file size. The remaining PE sections are comparatively small: .code at 14,336 bytes with entropy 5.61, .text at 54,272 bytes with entropy 6.56, and .rdata at 13,312 bytes with entropy 7.11. The functional code of the dropper itself is a thin shell; the payload is the resource section. The Zenbox sandbox names the family as Babadeda, a crypter-as-a-service tool documented as capable of encrypting payloads inside PE resource sections and decrypting them at runtime before execution [T1106]. The executes-dropped-file sandbox tag confirms that runtime extraction and execution of a secondary stage does occur.
Two of three sandboxes return a malicious verdict — Zenbox with confidence 48 (classifying the sample as MALWARE / TROJAN / EVADER) and Dr.Web vxCube also malicious — while C2AE returns undetected. The EVADER classification from Zenbox is significant: it indicates the sandbox's behavioural engine specifically identified evasion logic in the dropper, not merely malicious payload activity.
At the static-analysis layer, 40 of 76 engines flag the dropper. Engines including ALYac, AVG, Avast, CrowdStrike, ESET-NOD32, Kaspersky, and Microsoft are among those flagging; notable misses include AhnLab-V3, ClamAV, DrWeb, Fortinet, and NANO-Antivirus. The dropper also accumulates 14 Sigma rule matches across the GitHub integrated ruleset, with three at high severity — a meaningful signal that the behavioural profile of the dropper maps to multiple documented adversary technique patterns beyond the family-level detection.
The imphash for the dropper is 5877688b4859ffd051f6be3b8e0cd533. This hash is not shared with either of the two .NET implant components, which carry distinct imphashes (f34d5f2d4577ed6d9ceec516c1f5a744 for the EXE and dae02f32a21e03ce65412f6e56942daa for the DLL), confirming that the dropper was built in a separate toolchain environment from the inner payload pair — a structural separation consistent with the operator sourcing the Babadeda crypter as a service and preparing the .NET implants independently.
Active Evasion: Debugger Detection, WMI Reconnaissance, and Long-Sleep Delays
The dropper does not simply extract and execute its payload. Before doing so, it performs active environmental checks designed to defeat both automated sandbox analysis and manual debugging. The detect-debug-environment tag is present on 5b03e6e7, indicating the dropper queries for the presence of a debugger or analysis environment at runtime [T1622]. If such an environment is detected, the expected behaviour is to suppress the malicious payload execution, presenting the sandbox with a benign or incomplete execution trace.
The long-sleeps tag on the same sample indicates the dropper introduces deliberate timing delays — a complementary evasion technique targeting sandboxes that impose a time budget on dynamic analysis. A dropper that sleeps for several minutes before executing its payload will exhaust the analysis window of many automated systems, which will report the sample as undetected or inconclusive. This is consistent with the C2AE sandbox returning an undetected verdict while Zenbox, which may apply a longer or more aggressive execution window, returns malicious.
The calls-wmi tag adds a third dimension to the dropper's pre-execution behaviour. Windows Management Instrumentation calls at this stage of the chain are consistent with host reconnaissance [T1518] — enumerating installed software, security products, or system configuration to determine whether the target environment is suitable for full payload deployment. The campaign MITRE set includes T1012 (Query Registry) and T1518.001 (Security Software Discovery), both of which align with this WMI usage pattern. The combination of debugger detection, timing evasion, and WMI-based reconnaissance in a single dropper component represents a mature pre-execution gate: the payload is only released into environments that pass all three checks.
The main implant EXE (19a7262e) also carries the detect-debug-environment tag, meaning the anti-analysis logic is not confined to the dropper stage — it persists into the second execution layer. This layered application of debugger detection across both the outer and inner components suggests the operator is applying a consistent build-time configuration to all managed components, or that the Dotfuscator obfuscation pipeline itself injects this check as a standard feature.
The Implant Pair: A Unified Dotfuscator Build Pipeline
The two .NET components that constitute the inner payload layer — DriverEasy.exe (19a7262e3f6f3499913849ab5b30fe038533dbcb4492e25eb5ad2610c79a68d0) and Easeware.Driver.Core.dll (6135b4588ea0265d17f68382906d5b5ac2dcfd7dbab499e1528ac9244837e133) — are bound together by three independent cohort axes that collectively confirm they were produced in the same build session.
First, both carry a PE compile timestamp of 2025-09-28 — the same date as their first VirusTotal submissions, indicating the timestamps are authentic rather than forged, and placing the implant build approximately seven months before the dropper's first submission in April 2026. This temporal gap is itself a signal: the .NET components may have been prepared and staged well before the dropper that delivers them was finalised or deployed, consistent with a modular development approach where payload and delivery mechanism are built and tested independently.
Second, the YARA rule INDICATOR_EXE_Packed_Dotfuscator — authored by ditekSHen and distributed in the indicator_packed ruleset — fires on both samples. This rule specifically detects executables processed through Dotfuscator, a commercial .NET obfuscation product that renames symbols, inserts control-flow obfuscation, and can encrypt string literals. The co-firing of this rule across both components is the strongest single indicator of a unified build pipeline: the operator ran both the EXE and the DLL through the same Dotfuscator configuration before packaging them for deployment.
Third, both samples carry the PEiD packer signature, corroborating the YARA finding at the packer-detection layer. The cohort index records the PEiD cohort at size 2, with 19a7262e and 6135b4588ea0265d17f68382906d5b5ac2dcfd7dbab499e1528ac9244837e133 as the sole members — no other samples in the collection share this packer signature.
The size differential between the two components is notable. The EXE (19a7262e) is 1,314 KB with a .text section of 1,061,376 bytes at entropy 7.69 — a high-entropy code section consistent with heavily obfuscated managed code. The DLL (6135b458) is 603 KB with a .text section of 615,424 bytes at entropy 5.94, suggesting somewhat less aggressive obfuscation or a smaller functional footprint. The DLL's .reloc section registers entropy of 0.10, consistent with a sparse relocation table typical of .NET assemblies.
Detection ratios diverge significantly between the two components. The EXE (19a7262e) is flagged by 38 of 76 engines, with ALYac, APEX, AhnLab-V3, Arcabit, BitDefender, CrowdStrike, Fortinet, Microsoft, Sophos, and Symantec among those detecting it; engines missing include AVG, Avast, Avira, ClamAV, ESET-NOD32, Elastic, F-Secure, and Kaspersky. The DLL (6135b458) is flagged by only 19 of 77 engines — roughly half the detection coverage of its companion EXE — with ALYac, Alibaba, BitDefender, Google, Microsoft, and Sophos flagging, while AVG, Avast, Avira, CrowdStrike, ClamAV, Cylance, Cynet, ESET-NOD32, Elastic, and F-Secure all miss it. The DLL also carries a community vote of 0 malicious / 1 harmless, indicating at least one analyst or automated system has assessed it as benign — a reflection of how effectively the Easeware product branding and the lower detection ratio combine to create ambiguity at triage.
The DLL's recorded alt-names expose the persistence path: %APPDATA%\easeware.driver.core.dll and C:\Users\<USER>\AppData\Roaming\Easeware.Driver.Core.dll. Staging a DLL to a user-writable AppData path is a well-documented persistence and side-loading technique [T1105] that does not require elevated privileges and survives user-session persistence. The path mimics a legitimate Easeware installation directory, reinforcing the masquerade at the filesystem level.
Credential Capture and the Collection Stage
The trojanized DriverEasy.exe (19a7262e) carries the checks-user-input tag, and the campaign's MITRE attribution includes T1056 (Input Capture) and T1056.004 (Credential API Hooking). The combination of these two signals — a behavioural tag indicating the binary monitors user input and an explicit MITRE technique attribution for credential API hooking — suggests the implant is designed to intercept credentials entered by the victim during normal system use. This is consistent with the broader espionage motivation attributed to Gamaredon Group in the structured input.
It is important to be precise about the evidence basis here: no sandbox in the available data slice directly confirms keylogging or API hooking behaviour for this sample. The C2AE sandbox, the only one that processed the EXE, returned an undetected verdict. The credential-capture inference rests on the checks-user-input tag combined with the MITRE technique attribution — a medium-confidence inference rather than a confirmed behavioural finding. The absence of sandbox confirmation may itself reflect the anti-analysis measures embedded in the EXE: the same detect-debug-environment tag that appears on the dropper is also present on 19a7262e, and a sample that detects the sandbox environment before activating its credential-capture logic will present as benign in automated analysis.
The campaign's MITRE set also includes T1059.001 (PowerShell) and T1059.003 (Windows Command Shell), T1070 and T1070.004 (Indicator Removal / File Deletion), T1083 (File and Directory Discovery), T1112 (Modify Registry), T1548 and T1548.002 (Abuse Elevation Control Mechanism / Bypass UAC), T1553.005 (Mark-of-the-Web Bypass), T1562.001 (Disable or Modify Tools), and T1614.001 (System Language Discovery). This is a broad technique set that extends well beyond what the three characterised files alone can account for, suggesting either that the uncharacterised fourth file (3ac8c6b65eb99578317443cee8508cf120e0bd2d48de880b144bf109f6d4208b) carries additional functionality, or that the MITRE attribution draws on broader Gamaredon Group tradecraft patterns rather than being derived exclusively from this specific file cluster.
The system language discovery technique (T1614.001) is particularly worth noting in the context of a campaign that carries the Portuguese-language alias Ativador.exe. If the implant checks the system language before activating, it may be designed to avoid execution on Portuguese-language systems — a common self-exclusion pattern used by operators who do not want to infect systems in their own region or language community — or conversely, to target Portuguese-speaking environments specifically. The available data does not resolve this ambiguity, but the co-occurrence of a Portuguese filename alias and a system language discovery technique in the same campaign is unlikely to be coincidental.
The Uncharacterised Component and the Network Blind Spot
Two significant analytical gaps constrain the completeness of this assessment. The first is the fourth file in the indicator catalog: SHA256 3ac8c6b65eb99578317443cee8508cf120e0bd2d48de880b144bf109f6d4208b. This entry carries no type, size, detection ratio, threat label, sandbox verdict, or submission metadata — it is entirely uncharacterised and cannot be placed in either the Babadeda dropper cohort or the Dotfuscator .NET implant cohort. Its presence in the collection is unexplained by available evidence. Given that the three characterised files account for the dropper, the main implant EXE, and the companion DLL, the fourth file is a candidate for an additional component not yet submitted to public repositories — potentially the actual post-exploitation payload, a separate persistence mechanism, or a network communication module that would resolve the campaign's C2 picture.
The second gap is the complete absence of network infrastructure from the indicator set. The campaign carries zero IP addresses, domains, or URLs. This is the most operationally significant gap in the current data slice: without C2 endpoints, the campaign's tasking, operational tempo, and victim-selection logic cannot be assessed. The absence of observable infrastructure could reflect several non-exclusive possibilities. The operator may be using legitimate cloud services or compromised third-party infrastructure for C2, which would not generate novel domain or IP indicators. The network activity may be confined to environments not connected to public telemetry sources. Or the collection coverage simply has not yet captured the network layer of this campaign.
Gamaredon Group has historically made extensive use of dynamic DNS services and frequently rotates C2 infrastructure — a pattern that, if applied here, would explain why no stable network indicators have surfaced in the current snapshot. The DLL component staged to %APPDATA%\easeware.driver.core.dll is the most likely candidate for the C2 communication role based on its persistence path and the T1105 (Ingress Tool Transfer) attribution in the campaign MITRE set, but this inference rests on documented Gamaredon implant staging patterns rather than direct observation of network behaviour from this specific sample.
Gamaredon Attribution and the Cracked-Software Distribution Hypothesis
CTX Team attributes this cluster to Gamaredon Group — also tracked under the aliases Shuckworm, Aqua Blizzard, UAC-0010, Primitive Bear, Armageddon, and approximately a dozen additional designations — with an espionage motivation and construction-sector targeting recorded in the structured input. The attribution carries high confidence based on the structured data.
The construction-sector targeting is notable. Gamaredon Group's documented focus has historically concentrated on Ukrainian government, military, and critical infrastructure targets. Construction-sector targeting may reflect interest in project data, procurement networks, or personnel with access to sensitive sites — a targeting rationale consistent with intelligence collection objectives rather than financially motivated intrusion.
The distribution mechanism — a trojanized installer circulating under the Portuguese-language alias Ativador.exe through what the analyst assesses as cracked-software channels — is worth examining as a potential tradecraft evolution. The cracked-software distribution vector, if confirmed, would represent a departure from more precisely targeted delivery mechanisms and a shift toward broader initial-access reach at the cost of less precise victim selection [T1204.002]. This inference is drawn from the Ativador.exe alias and the unsigned installer format; it is an analytical assessment rather than a confirmed documented TTP shift, and should be treated as medium-confidence pending additional collection. No prior named campaigns or historical arc claims are available in the current evidence base to contextualise this as a documented evolution.
What the Evasion Stack Signals About Operational Calibration
The detection ratios across the three characterised components — 40/76 for the dropper, 38/76 for the main EXE, 19/77 for the DLL — are not accidental. They reflect a deliberate calibration of obfuscation depth against detection visibility. The dropper, which is the most exposed component (it must be distributed and executed by the victim), receives the most aggressive treatment: Babadeda crypter packaging, timestamp forgery, and active sandbox evasion. The main EXE receives Dotfuscator obfuscation and debugger detection. The DLL, which is dropped to a user-writable path and likely never directly executed by the victim, receives the lightest treatment — and achieves the lowest detection ratio as a result, sitting below the broad-consensus detection threshold where most automated triage systems would not flag it as a priority.
This gradient of obfuscation investment — heaviest at the point of initial exposure, lightest at the persistence layer — is consistent with an operator who understands where in the kill chain detection is most likely and has allocated obfuscation resources accordingly. The YARA rule INDICATOR_EXE_Packed_Dotfuscator co-firing on both .NET components is the detection community's current best handle on this inner layer; the rule's presence in the ditekSHen indicator_packed ruleset means it is broadly deployed, but 53 of 77 engines still miss the DLL entirely, indicating the obfuscation remains effective against the majority of the scanning population.
The combination of a Babadeda-crypted outer layer with a Dotfuscator-obfuscated inner layer represents a two-vendor obfuscation strategy: the operator is not relying on a single tool whose signatures might be broadly known, but layering a crypter-as-a-service product over a commercial .NET obfuscator. This is a resource investment that points toward an operator with access to multiple obfuscation toolchains and the operational discipline to apply them in a coherent architecture rather than opportunistically.
The cracked-software distribution vector, if the Ativador.exe alias and the submission path evidence are read correctly, adds a scalability dimension to this picture. A campaign that reaches victims through pirated software repositories does not need to invest in spear-phishing infrastructure or targeted delivery mechanisms — the victim self-selects by seeking out and executing the trojanized package. The trade-off is victim precision: the operator accepts a broader and less predictable victim pool in exchange for a distribution channel that requires no active targeting infrastructure. For an espionage actor whose tasking may include broad collection from a sector rather than precision targeting of named individuals, this is a rational operational choice.
The uncharacterised fourth file remains the most pressing analytical priority. Its presence in the collection without any metadata suggests it has not yet been submitted to public repositories or has been submitted in a form that prevents automated analysis — either of which is consistent with a component that the operator has taken specific steps to protect from public exposure. Until that file is characterised and the campaign's network infrastructure is identified, the full operational scope of this cluster — including its actual C2 protocol, exfiltration mechanism, and victim-selection logic — remains unresolved.