Loading malware…
BabaDeda is a Windows malware loader stage used in a multi-step intrusion chain that culminates in deployment of the CNCMachineRMS remote access trojan. The family name derives from an internal initialization marker used by the shellcode. BabaDeda is not a full-featured payload by itself; it functions as an intermediate execution and decryption component that depends on a separate serialized configuration container holding tasking logic and an embedded next-stage payload.
Observed BabaDeda activity has been associated with ClickFix social-engineering lures that trick victims into launching a trusted signed application. The chain abuses IBM SPSS WinWrap Basic IDE to activate malicious COM-directed scripting and then advances through multiple decoy DLLs, culminating in shellcode execution through a legitimate Windows API callback path. This design blends malicious execution into normal module loading and Windows control flow, while avoiding more conspicuous script-based tooling.
Technically, BabaDeda resolves APIs by hash, reconstructs strings at runtime, and uses an external property-tree style configuration format rather than a simple standalone encrypted blob. The configuration container can include a task script that maintains persistence and an embedded final payload. In documented cases, BabaDeda has delivered CNCMachineRMS, a Windows RAT with interactive shell access, file management, screenshot capture, host profiling, persistence management, local account backdoor creation, and staged payload execution. BabaDeda therefore serves as a loader and execution bridge for post-compromise tooling rather than as an infostealer or commodity standalone RAT.
The malware chain using BabaDeda has targeted Windows environments and has been linked to campaigns aimed at cryptocurrency, NFT, and DeFi communities. BabaDeda has also been discussed alongside payload families such as Remcos, indicating that it can act as a flexible delivery component for different downstream malware. Its use of DLL sideloading, in-memory shellcode execution, runtime string construction, and obfuscated external configuration reflects a strong emphasis on defense evasion and modular payload delivery.
Mallory pivots from this family to the IOCs, detections, and named campaigns that touch your stack, and pages you when something new lands.
15 distinct techniques documented for this family, organized by ATT&CK tactic.
Persistence is re-asserted on a loop every 150 seconds for the registry and every 875 seconds for the scheduled task... The same string is used as the scheduled task name.
After the ClickFix lure, attackers launch IBM SPSS WinWrap Basic IDE and steer its scripting function toward malicious files.
It passes the shellcode through EnumTimeFormatsEx, a harmless Windows date-formatting interface, so Windows itself calls the code.
From there, a run of four decoy DLLs loads through ordinary import resolution, with no suspicious API calls and no odd LoadLibrary to flag.
The attackers exploit its ability to activate a scripting engine through COM, directing it to a dropped DLL.
Persistence is re-asserted on a loop every 150 seconds for the registry and every 875 seconds for the scheduled task... The same string is used as the scheduled task name.
There are no cleartext APIs or strings anywhere in the shellcode. APIs are resolved at runtime from hashes, and strings are built on the stack by a custom cipher.
The last decoy fills a buffer with random data, places shellcode inside it, and makes the memory executable.
In this case, WinWrapIDE.exe is clean and legitimately signed. The attackers exploit its ability to activate a scripting engine through COM, directing it to a dropped DLL.
Before any of that, the decoy library fingerprints the environment: computer name, username, system and Windows and temp and current directory paths, tick count, system and local time... alongside sandbox and analysis evasion checks.
Every module opens directly from the application directory, with no failed search path probe first.
18 indicators attributed across vendor reports, sandbox runs, and researcher write-ups. Full values are available in Mallory.
IPs, domains, and DNS infrastructure linked to this family.
File hashes (MD5, SHA-1, SHA-256) from samples and reports.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A shellcode-based loader stage in the infection chain. It relies on a separate configuration file and is used to load the embedded CNCMachineRMS payload, making partial samples appear less suspicious during quick automated analysis.
A memory-only shellcode stage in the loader chain that depends on an external configuration file and is used to unpack/load the embedded CNCMachineRMS payload.
A shellcode stage in the infection chain that relies on an external configuration file and embedded script to ultimately load the CNCMachineRMS payload. It appears to function as a loader rather than the final implant.
An intermediate shellcode stage used in the loader chain. By itself it is minimally functional and depends on a separate config file containing an obfuscated configuration tree and the embedded CNCMachineRMS payload.
Match every observed IP, domain, and hash against your live telemetry.
Named campaigns wielding this family, with evidence pinned to each claim.
CVEs this family uses for access and lateral movement.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Every documented technique, ranked by evidence weight.
Reddit, Mastodon, and CTI community discussion around this family.