Loading malware…
BabaDeda is a Windows shellcode stage used in a ClickFix-driven intrusion chain that ultimately deploys the CNCMachineRMS remote access trojan. By itself, BabaDeda has limited standalone functionality and depends on a separate configuration component containing an obfuscated configuration tree, a script, and an embedded CNCMachineRMS payload. In the observed execution chain, attackers abused the legitimately signed IBM SPSS WinWrap Basic IDE executable to activate scripting through COM, chained execution through multiple decoy DLLs, and invoked BabaDeda shellcode via the Windows EnumTimeFormatsEx API to reduce detection and make intermediate artifacts appear benign.
BabaDeda functions as an in-memory staging component rather than the primary operator implant. Its role is to load and interpret external configuration data and facilitate execution of the embedded CNCMachineRMS payload. The broader intrusion sequence used memory-resident stages, decoy DLLs, and trusted application abuse as defense-evasion measures. Delivery was associated with ClickFix social engineering in which victims were tricked into running a malicious command disguised as a routine fix.
BabaDeda is associated with hands-on-keyboard post-compromise activity because it serves as the precursor to CNCMachineRMS, a flexible remote administration implant. The downstream payload supports interactive shell access, file management, screenshot capture, persistence, local account creation, host profiling, and retrieval and execution of additional payloads. The overall tradecraft indicates an intrusion set focused on stealthy staging and operator-controlled follow-on access on Windows systems.
Mallory pivots from this family to the IOCs, detections, and named campaigns that touch your stack, and pages you when something new lands.
7 distinct techniques documented for this family, organized by ATT&CK tactic.
The attackers exploit its ability to activate a scripting engine through COM, directing it to a dropped DLL.
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.
It has no imports. Every string is built on the stack at runtime instead of sitting in the binary. Its config and its command and control (C2) traffic travel in the same custom binary container... That file, HelperStandardizationApplication.bin, looks like an encrypted blob at 8 bits of entropy per byte. It is not encrypted. It is a configuration tree under two layers of obfuscation...
2 indicators attributed across vendor reports, sandbox runs, and researcher write-ups. Full values are available in Mallory.
File hashes (MD5, SHA-1, SHA-256) from samples and reports.
3 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.
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.