Overview

On August 31, 2026, ReliaQuest published a threat spotlight on a Windows attack toolkit its researchers call Gryxa — a name the company assesses is the first documented case of a threat actor using a commercial AI coding agent to help build and operate an attack ecosystem at meaningful scale. The operator is financially motivated, not affiliated with any known APT, and — per ReliaQuest's review of the actor's public code repository — appears to lack prior development experience. The repository's commit history lists the AI coding agent as co-author on most commits, alongside engineering notes, session handover documentation, and case files tracking 35 documented failed installation attempts that the operator worked through with the agent's help.

What makes Gryxa notable is not any single novel exploit. It combines already-known techniques — RMM abuse, scheduled-task persistence, WMI event subscriptions, browser credential theft — into a toolkit resilient enough that ReliaQuest's own review found deleting the visible remote-access client or install folder was not sufficient to evict it: surviving components could rebuild the operation within minutes. Its most unusual capability surfaces only after a defender responds: a component left running after partial remediation collects Windows logs and host artifacts documenting exactly which tools and accounts the responder used, then exfiltrates that data to the operator's infrastructure — turning an incomplete cleanup into intelligence for the attacker.

At the time of ReliaQuest's review, the operator's web-based fleet console listed 324 hosts under management, with 69 shown online. Not every listed host could be independently confirmed as an active victim, but the scale is consistent with an individual operator running an operation that would previously have required a small team.

This post surveys what is currently public about Gryxa's attack chain, its infrastructure, and how defenders should detect and respond to it — with an explicit note that its centralized update pipeline can rotate component files and hashes quickly, so static IOC matching alone is a weak long-term control.

Threat Actor Profile

Gryxa's operator is unattributed and assessed as financially motivated. Unlike Operation Poisson (a French-speaking junior operator whose OPSEC failures exposed his entire playbook), Gryxa's operator left comparatively little identifying detail in public reporting beyond the repository artifacts ReliaQuest reviewed. What is documented:

• Skill level: Assessed as lacking prior development experience; the toolkit's sophistication is substantially attributable to AI-agent assistance rather than the operator's own engineering skill.
• AI agent interaction pattern: Rather than using the AI coding agent for isolated one-off tasks (generating a single command, processing stolen data), the operator used it across the full development lifecycle — building the toolkit itself and the web-based fleet management console. ReliaQuest's repository review found the operator represented the work to the AI agent as authorized security testing, a claim inconsistent with the toolkit's actual deployment against several hundred apparently non-consenting hosts.
• Iteration pattern: 35 documented failed installation attempts, worked through collaboratively with the AI agent, point to an iterative build-test-fix cycle rather than a single polished release — consistent with a developer learning the platform as they built the tool.
• Operational scale: A centralized fleet console with host counts, live/offline status, and queued job management — infrastructure normally associated with commercial RMM products, repurposed for illegitimate fleet management.

This is a meaningfully different profile from most MaaS or leaked-builder cases (see HookBot/DukeEugene coverage in this research series): Gryxa's toolkit does not appear to trace to an existing malware family's leaked source. It reads as a bespoke build, made possible at this skill level specifically because of AI-agent assistance.

Infrastructure

ReliaQuest's naming of wirbe.com as "current" infrastructure alongside gryxa.com/seczio.com/sevrz.com as "legacy infrastructure still in use" suggests the operator has rotated primary domains at least once while continuing to run older infrastructure in parallel — a pattern worth tracking for future domain rotations.

Attack Chain: Stage by Stage

Stage 1 — Initial Access (Invoice-Themed Lure)

The suspected entry point is a phishing message carrying a 19 MB self-extracting executable disguised as an invoice, following the naming pattern invoice_<10 digits>.exe. Once launched, the installer retrieves additional components over HTTPS from actor-controlled infrastructure and public code-hosting services.

Stage 2 — RMM Abuse for Covert Access

Rather than deploying a fully custom remote-access trojan, Gryxa turns legitimate remote monitoring and management (RMM) software into a hidden control channel — a technique with growing precedent across financially motivated intrusion sets, since signed RMM binaries are far less likely to trip AV/EDR file-reputation checks than a bespoke implant.

Stage 3 — Persistence Layering

Gryxa distributes hidden files across several ProgramData locations, including a primary working directory named WinRTCS and folders disguised as Windows Error Reporting and Diagnostics caches (.wucache, .etlcache). On top of this, it layers redundant persistence:

• At least seven scheduled tasks, three of which run as SYSTEM at one-, five-, and 15-minute intervals
• A permanent Windows Management Instrumentation (WMI) event subscription
• An off-path backup copy of toolkit files (C:\ProgramData\Microsoft\WinRTCS\cache\)

Because these mechanisms restore one another, removing only the visible RMM client or the primary install directory leaves enough surviving components to rebuild the toolkit, often within about a minute.

Stage 4 — Anti-Remediation Guard and Defender Tampering

Gryxa's guard component checks in with the actor's relay approximately every five minutes. After two consecutive failed check-ins, it attempts to disable Microsoft Defender and stop hard-coded EDR services. After a third consecutive failure, it retrieves the security product's uninstall command from the Windows Registry and attempts a silent uninstall. The full sequence — from relay loss to attempted EDR removal — can unfold in roughly 10 to 13 minutes.

This means the order of remediation operations matters: cutting off only the remote-control channel first, without also isolating the host and removing persistence in a single coordinated action, can trigger the very tampering behavior defenders are trying to prevent. Gryxa may also later re-enable Defender once its relay connection returns, while leaving exclusions in place — so a healthy-looking Defender status is not proof a host is clean.

Stage 5 — Credential Theft and Exfiltration

Gryxa targets credentials saved in Chromium-based browsers, including cryptocurrency exchange and fintech accounts, and contains multiple methods intended to defeat Chrome's App-Bound Encryption (a protection specifically introduced to make non-browser-process credential decryption harder). ReliaQuest verified these methods through code review but did not independently confirm successful decryption across every claimed browser/version. Decrypted credentials are reportedly exfiltrated through Telegram bots, while any wallet browser extensions found are cataloged for later manual access. Because the toolkit decrypts all accessible browser data before filtering against its target list, organizations should treat every credential stored in a reachable browser profile as exposed if the credential module ran — not only crypto-related ones.

Stage 6 — Post-Remediation Intelligence Collection

Gryxa's most distinctive capability activates after a defender responds. If the visible RMM implant is removed but a hidden Gryxa component survives, that component collects Windows event and service logs, process-creation records, scheduled-task and WMI configuration details, an inventory of remote-access tools present, and indicators of the attacker's surviving communication channel. It archives and uploads this data to attacker infrastructure — potentially revealing which tools, accounts, and sequence of actions the responder used, information the operator can use to adapt future intrusions or specifically target the responding team's own access.

Detection Guidance

Process and Host-Level Detections (Windows EDR / Event Log)

Scheduled task creation in Gryxa-associated paths. Security Event ID 4698 (scheduled task created) where the task content or command line references C:\ProgramData\WinRTCS, .wucache, or .etlcache should alert regardless of the specific task name used, since exact task names were not published and may vary by build.

SYSTEM-level tasks at unusual short intervals. Multiple scheduled tasks created in a short window, running as SYSTEM at 1-, 5-, or 15-minute intervals, is a stronger behavioral signal than any single task name and is harder for the operator to evade by renaming.

Windows Defender / EDR service state changes without an administrative change ticket. Service Control Manager events (7036 and related) showing WinDefend or a named EDR product stopping, especially in a burst following a period of C2 unreachability, should be treated as high-priority — this is the observable side effect of Gryxa's anti-remediation guard countdown.

WMI permanent event subscriptions. A new __EventFilter/__EventConsumer/__FilterToConsumerBinding triple (Sysmon Event ID 19/20/21, or the WMI-Activity operational log) on an endpoint that has no legitimate WMI-based monitoring deployed is a high-fidelity persistence indicator.

Invoice-themed self-extracting executables. Process creation for files matching invoice_<10 digits>.exe, particularly from email-client or browser-download parent processes, warrants alerting independent of file hash.

Uninstall-protection bypass attempts. Registry queries or command execution retrieving an installed security product's uninstall string, especially following recent RMM or scheduled-task activity, should be flagged as a likely precursor to tampering.

Network-Level Detections

Monitor DNS resolution and HTTPS connections to wirbe.com and its subdomains (world, cdn, ver, mesh), plus the legacy-but-still-active gryxa.com, seczio.com, and sevrz.com domains and subdomains, along with direct connections to 144.172.107.56 and 209.145.55.189. Because ReliaQuest notes the operator has already rotated primary domains once, treat any newly registered domain sharing WHOIS/hosting infrastructure characteristics with these as worth investigating.

Identity and Credential-Layer Detections

Any environment where Gryxa is suspected should assume all credentials stored in reachable Chromium browser profiles were exposed, not just cryptocurrency-related ones, and force a credential rotation for affected users. Monitor for anomalous Telegram Bot API traffic originating from endpoint processes rather than an approved messaging client — this is Gryxa's documented exfiltration channel.

Response Sequencing

Because of the anti-remediation guard described in Stage 4, ReliaQuest's recommended response order is: block known actor infrastructure at the network edge first, isolate the affected endpoint where possible, then remove the scheduled tasks, WMI subscription, hidden working directories, backup files, and the RMM implant together in one coordinated action — not the visible RMM session alone, and not piecemeal over an extended window. Endpoint products with uninstall protection should have that control enabled before response actions begin, and responders should avoid deploying a new remote-access tool onto a still-live compromised host, since Gryxa may treat it as a rival tool and attempt to uninstall it.

Indicators of Compromise

Network

Host Artifacts

Note: No durable file-hash IOCs are published for this toolkit. ReliaQuest and follow-on reporting explicitly attribute this to Gryxa's centralized update/build pipeline, which can regenerate and redeploy component files (and therefore hashes) quickly. Treat the behavioral indicators above as the primary detection surface; file hashes, if later published, should be layered on top rather than relied on alone.

MITRE ATT&CK Mapping

Key Takeaways

AI-agent assistance is lowering the skill floor for durable attack infrastructure, not just faster scripting. Gryxa's operator is assessed as lacking prior development experience, yet built a toolkit with layered, self-healing persistence and a working fleet-management console — capability historically associated with a small development team, not a single individual working with an AI coding assistant across 35 documented failed builds.

Behavioral detection beats hash matching here by design, not by preference. Gryxa's centralized update pipeline means file hashes are a moving target. Scheduled-task creation paths, WMI persistence, and Defender-tampering sequences are comparatively durable signals because they follow from the toolkit's architecture rather than any specific build.

Remediation order matters. The anti-remediation guard's 10-13 minute countdown from C2 unreachability to attempted EDR uninstall means a partial or staged takedown can trigger exactly the tampering defenders are trying to avoid. Coordinated, simultaneous removal — network block, host isolation, then full persistence-layer cleanup — is the documented safe sequence.

Partial remediation can become a intelligence gift to the attacker. Gryxa's post-cleanup log-collection behavior is a meaningful escalation beyond typical persistence toolkits: an incomplete response doesn't just fail to evict the attacker, it can actively inform their next move against the same environment.

References

1. ReliaQuest. (2026, August 31). Threat Spotlight: Gryxa — An AI-Built Toolkit. https://reliaquest.com/blog/threat-spotlight-gryxa-ai-built-toolkit/

2. Dutta, T. S. (2026, August 31). New AI-Built Malware Watches How Security Teams Remove It and Fights Back. Cyber Security News. https://cybersecuritynews.com/new-ai-built-malware-watches/

3. Kathir, M. (2026, August 31). New Gryxa Toolkit Uses AI-Built Persistence to Fight Back Against Security Teams. GBHackers. https://gbhackers.com/gryxa-toolkit-uses-ai/

4. OffSeq Threat Intelligence. (2026, August 31). Toolkit: AI-Assisted Development and Persistent Threat Operations. OffSeq Threat Radar. https://radar.offseq.com/threat/toolkit-ai-assisted-development-and-persistent-threat-operations-194c32b91cc7dc2b

5. IT Brief. (2026, August 31). AI Helped Build Gryxa Malware Operation, Report Says. https://itbrief.co.nz/story/ai-helped-build-gryxa-malware-operation-report-says