Exposing the TGSEC operation

Key judgments

HackersEye’s investigation exposes more than attacker tooling: it documents a cyberattack operation engineered to run continuously and autonomously. An AI-oriented operator repository, a documented collection backend and the later distribution of ARTEX builds connect into one always-on system. The new infrastructure evidence brings that system into focus: a master host, a 12-shard collection fleet and a visible search-and-export interface, the working machinery of an operation that does not stop when its operator steps away.

HackersEye assesses a Chinese-language operator maintaining the arsenal and conducting financial-sector enumeration, with medium confidence in financial motivation. The incident linkage is narrower: a scanner/reconnaissance component is associated at medium confidence; responsibility for that incident’s breach or credential-harvesting phase is not established by this evidence.

Why we are exposing this operation

We investigated TGSEC to understand how its operator connects exposed applications, identity data and business relationships. The goal is to help organizations recognize relevant activity, contain access that may already exist, and protect people whose data could be affected.

The important shift is the accumulation of knowledge. A public application reveals a workflow; a weak recovery step may expose an account; a configuration file may reveal a connected service. Stored as reusable instructions and operational memory, those discoveries can lower the effort required for the next attempt. The repository shows that knowledge being organized. The case material shows why its subject matter matters.

We publish useful infrastructure and detection leads while withholding client identities, personal records and usable secrets.

What the operator appears to value

Our assessment is that this operation treats identity, trusted relationships and reusable access as valuable assets. A trading portal can expose an identity and its financial context; a supplier platform can connect several organizations; a configuration store can describe how production services trust one another. The organized collection backend adds a way to search and retrieve accumulated material.

HackersEye assesses financial motivation with medium confidence. The evidence does not establish a completed sale, a payment-fraud event or a single motive for every engagement. The case studies below therefore separate the reported exposure from the opportunities we assess it could create.

What coordinated AI could change for cybercrime

Our assessment is that coordinated agents could make a capable operator’s attention go further. Several workers can investigate different leads, pass useful discoveries back to a planner and preserve the results for reuse. A weakness found in one integration can become a starting point for the next engagement. The commercial opportunity is repeatable work across more targets, although this evidence does not measure an increase in intrusion success.

“Swarm” needs precision here. The repository documents twelve collection stations and separately describes agent-oriented tooling. That does not establish twelve autonomous AI agents carrying out intrusions. The concern for defenders is coordinated work and accumulated knowledge, regardless of how many steps still require a person.

Organizations should plan for several access paths being tested at once. Correlate behavior across sessions and changing IP addresses, constrain service identities, and investigate the downstream reach of exposed credentials. Response teams need a shared picture of the activity so that blocking one source does not end the investigation while another path remains open.

The collection backend comes into view

A maintenance file in the preserved repository identifies a central collection controller. Supplied browser captures show a data-search and export interface associated with that controller. Its address and access details are censored from this publication.

The source describes a central data pool and a 12-station collection fleet. Together, the documentation and captures provide stronger infrastructure context than an isolated address in a commit message. Server ownership, software and the underlying records were not independently examined.

What the interface actually shows

The header displays 23,241,527 total rows and 367,376 phone-bearing rows. The enterprise-account tab displays 791,321 rows, matching the number offered by the filtered-export control. Other visible categories include purchase-order details, login profiles, account profiles, bidding records and audit feeds.

Those are interface counters. They do not establish unique individuals, unique businesses, accurate records, completed exports or a confirmed theft total. The source’s own counting notes warn that records can duplicate the same enterprise across collection paths and naming variants. Neither the counters nor category names alone prove that every record was obtained unlawfully.

The updated advisory associates the material with a freight/procurement ecosystem. That provenance is an assessment in the report; this review did not validate it with the platform owner. Visible phone, email, login-IP and organization fields demonstrate the sensitivity of the displayed record schema, so the publication graphics reproduce counters and structure only.

The 12 collectors are not the four relays

The source lists shards 0 through 11 and identifies a controller-side registry as its authoritative station inventory. It distinguishes the collectors from a four-host relay layer. Access commands, registry locations and key paths are censored; none of those systems or files was accessed during this review.

Two listed collectors, 39.96.146[.]230 and 8.130.150[.]18, were already present as cloud-host leads in the earlier evidence set. Their inclusion here supplies a more specific documented role; it does not independently verify current deployment. The source labels shard 3 Chengdu and shard 4 Shanghai, correcting the updated report’s Shanghai/unspecified labels.

What this changes in the actor assessment

The evidence now describes a maintained collection system with station inventory, merger/index components, a persistent data pool and a bot-facing presentation layer. It supports an assessment of sustained data acquisition and organized operation. Source references to an AI-oriented maintenance workflow do not establish that each collector is an autonomous AI agent.

The same-IP portal observation strengthens the link to the documented master. It does not by itself prove a particular intrusion, identify every dataset’s acquisition method, authenticate the operator’s identity or demonstrate a completed sale or laundering transaction. Financial-motivation and campaign-specific judgments retain their stated confidence limits.

What ARTEX does

The advisory describes a Hermes-first stack that accumulated skills and operational memory before the ARTEX release repository was created in late October. Earlier financial-sector activity should therefore not automatically be described as execution by the later ARTEX build. Commit author dates and operator notes support a development chronology; repository creation metadata alone does not prove when code became public.

ARTEX combines a planner, tool-enabled worker agents and accumulated knowledge about a target. The operator supplies intent. Agents divide it into tasks, run tools, inspect responses and choose what to try next. Microsoft describes a Go implementation with a Next.js interface and support for different AI models.

That feedback loop is the operational change. Scanning, exploitation and data collection can proceed through repeated tool calls without a person selecting each command. Google Threat Intelligence Group and Mandiant have observed ARTEX and related frameworks during incident-response engagements, including assistance with lateral movement, database exploitation and exfiltration preparation. GTIG and Mandiant analysis

These frameworks can support authorized testing. Their appearance in a repository or on an endpoint must be evaluated against the activity, scope and permissions surrounding their use.

Norma explains the framework lineage

The latest advisory adds the upstream source lineage. The surviving ARTEX mirror declares github.com/Autumn-27/artex as its module and depends on github.com/Autumn-27/norma v0.4.3. This is a direct code-dependency link to the author’s agent harness. It helps explain the reported norma/0.4 user-agent, while leaving the provenance of any particular downstream binary open.

Autumn-27’s profile statement, dated 8 October 2026, says malicious actors abused the tool and announces its closure to further public updates. That is the author’s statement, not independent proof about every use. The upstream author, public mirror maintainers and the TGSEC-linked distributor remain separate subjects; using or mirroring ARTEX does not establish malicious intent.

One framework across several campaign clusters

HackersEye’s advisory organizes the reporting into the following clusters. These are analytic groupings; different infrastructure does not, by itself, prove unrelated operators.

CrowdStrike’s investigation supports malicious ARTEX use against South Korean financial organizations, while leaving the number affected unconfirmed at publication. Shared tooling should not turn those findings into a single global victim count. CrowdStrike investigation

HackersEye finding: the TGSEC and ARTEX distribution link

The GitHub account lanyz1, account ID 189613774, owns three relevant repositories: TGSEC-Qtzuu, Qtzuu-pentest-toolbox and haidaochuan. Together they cover a knowledge library, an execution framework and a release channel.

HackersEye’s advisory identifies Autumn-27 as the original ARTEX author. The lanyz1 account is a separate downstream attribution subject. The public version lineage cited in the advisory and the v1.0.14 distribution names differ; establishing a fork or private build requires binary or source comparison.

The haidaochuan v1.0.14 release was published on 30 October 2026 at 20:39:51 UTC. It contains ARTEX archives for five platform/architecture combinations alongside TGSEC-toolkit-1.0.13-simple.zip. Co-distribution under one account directly links these toolsets.

A second link is recorded in commit e45b4feaadfb. Its message names 45.192.102[.]149 as a source of 16 distinctive skill cards. The changes add material concerning WAF triage, SSRF verification, real-time protocols and synchronization, among other topics. HackersEye’s advisory identifies the same address as TGSEC-associated infrastructure.

This corroborates an infrastructure reference in the repository’s development history. The endpoint’s specific C2/exfiltration role is the advisory’s assessment. Release names and metadata establish distribution, rather than code equivalence or proof that a binary ran in every campaign.

Distribution extends beyond the original account

The original three repositories remain anchored to lanyz1. The wider preservation set shows a larger content-distribution surface: five toolbox fork accounts and 14 non-fork repository observations across 12 additional owners. That is 17 distinct redistribution accounts, or 18 including the primary account, in the supplied captures. “Roughly 20” is a useful shorthand for the broader investigative set, but it should not become a count of proven actor-controlled accounts.

A non-fork re-upload can preserve every original author and committer label. Those labels travel with the content; they do not identify the person controlling the new account. Generated-looking handles and account-creation clusters are weak ownership clues, not sufficient grounds to label an account a malicious sockpuppet.

The defensive implication is resilience: removing an original repository does not remove its preserved snapshots elsewhere. Preservation and platform review need to distinguish the primary publisher from independent redistribution. Download the captured distribution observations.

Inside the operator repository

The collection is designed for reuse by tool-enabled AI assistants. A preserved October snapshot contains 2,226 skill documents across 12,920 files in the Hermes skill collection, including archived material. These are content counts, not numbers of exploits or enabled agents.

The routing layer maps questions and target characteristics to relevant material. The arsenal builder indexes skills and references, while a 30-query self-test checks retrieval results against expected keywords. That is an engineering investment in finding and reusing knowledge; it does not establish an attack success rate.

Bootstrap code copies client-specific instruction files and invokes synchronization and Hermes setup.

The companion toolbox describes a hypothesis-driven testing workflow and a hashed evidence ledger. The preserved ledger contains no completed engagement entries, so it cannot independently validate the reported impact.

The 1 November update: reports become reusable playbooks

The preserved 1 November update describes a report-to-playbook workflow. The 1 November report-distillation snapshot contains 2,330 skill documents across 13,024 files, an increase of 104 skill documents over the earlier snapshot. These are content counts, not numbers of agents, exploits, victims or successful attacks.

The maintainer says 127 deduplicated documents containing 2,474 findings were grouped into 29 technical families, producing 17 report-derived cards and strengthening 41 existing cards. Those input and finding totals remain operator claims. The associated change does add reusable technique material; its retrieval-test results measure whether relevant material can be found, not whether an intrusion succeeded.

For defenders, the significance is knowledge transfer. An observation from one assessment can become an instruction used in another. The update also describes filtering credential- and personal-data-only ledgers out of skill generation and sanitizing the publishing copy. That separates the public library from its operational sources; it does not independently establish the origin, authorization or outcome of the reported cases.

A library under active maintenance

Live GitHub metadata records repository activity on 1 November. A newer change adds four PHP skill cards that explicitly cite public php2shell research and amends an existing PHP card. This verifies incorporation into the library by that date. The cited research predates the update; the accompanying local-test result is a maintainer-authored claim, not an independently reproduced result or evidence of a victim intrusion.

The author metadata also changes from a platform-linked noreply address to an unlinked local Git address. GitHub’s account matching for commit emails does not identify the person who pushed a change, and it does not resolve the excluded legacy-account association. Recent forks show continued redistribution, but their timestamps do not establish automated mirroring after every push or common control.

The organizational implication is a shorter path from published research to reusable testing instructions. Defenders should prioritize weaknesses by exposure, reachable identities and downstream business trust, then validate controls with telemetry. Neither a new skill card nor an operator’s test note is proof that the technique was used successfully against an organization.

What the instructions reveal about tradecraft

Authorization is asserted inside the agent configuration

The project describes authorized testing, and the toolbox includes a scope gate. The Hermes persona instead directs the agent to presume authorization, avoid scope questions and operate against real external assets rather than substitute a lab. This is evidence of intended agent steering, not evidence that a model complied.

Operational memory emphasizes continuity and complete collection

The memory and user-preference files preserve lessons across work, demands for complete data collection and Telegram reporting. This supports an assessment of a persistent, data-oriented workflow. Recollections of access and delivery are operator-side claims until corroborated.

Publishing is separated from the operational copy

Dated update notes describe redacting credentials, personal information and the maintainers’ infrastructure from the public copy while retaining target addresses and methodological material. An operations-security note discusses an infrastructure address exposed in a commit message and an attempt to amend that history. These records show publication hygiene and concern about infrastructure attribution; redaction alone does not establish criminal intent.

Telegram is part of the delivery capability

Delivery recipes describe inventories, archives and splitting large collections for Telegram transmission. That supports a data-delivery capability assessment. It does not, on its own, verify a particular bot’s C2 role or a gambling-settlement function.

Untrusted instructions can reach the investigator’s own agent

The updated advisory reports an isolated handling event in which an AI coding assistant registered 15 repository skills. The relevant files include root-level agent instructions, client configuration and skill directories. Those files can enter an assistant’s context when it discovers the workspace; their contents must remain untrusted repository material.

This review did not reproduce that event. Cloning content and registering skills are distinct from executing a tool or contacting a target. The practical boundary is the assistant’s instruction-loading behavior: examine unfamiliar repositories as inert text, inspect entry files and skill metadata, and approve loading deliberately.

Actor assessment

No reviewed evidence establishes common control with Storm-0940 or the South Korean finance operator. The original ARTEX author, downstream maintainers and campaign operators must also remain separate attribution subjects.

Excluding a legacy username match

A legacy username association was excluded after review. A commit label or noreply-email match does not establish who controlled an account or campaign.

Declared infrastructure and hosting context

The commit-message addresses are only one layer. A historical sweep records three additional addresses inside pre-redaction ai-config/hermes/MEMORY.md, subsequently replaced by own-infrastructure placeholders. This makes them a distinct declared-infrastructure set.

The paired Nebula Global addresses are a useful hosting and preservation pivot. They are not proof of common customers elsewhere in that ASN, the operator’s physical location or legal ownership of the addresses. The ASN/provider labels reproduce the engagement’s 1 November Team Cymru enrichment record; they have not been freshly queried for this article.

Control, relay and associated cloud layers

The advisory documents an SSH relay fleet separately from the declared MEMORY addresses. The IOC report enriches those fleet entries as AS4816, AS58519, AS58461 and AS136188. Cloud-host references below are a lower-confidence association set whose exact operational role needs confirmation.

Domain leads remain review-only

aigc.kartai88[.]com, aigc.umi6[.]com, api.wallet8[.]top and apixx5daguo[.]cc appear in the review set. Their presence is not enough to assign C2, monetisation or malicious-service roles. Keep them separate from confirmed infrastructure and automated blocking inputs.

Download the classified infrastructure observations. Source confidence, role uncertainty and snapshot date are retained in the file.

Targeting and claimed impact

The updated advisory describes material covering online gambling, card-issuing and digital-goods storefronts, crypto platforms, enterprise procurement and Israeli capital-markets institutions. These are categories in the engagement documentation and skill collection; not every directory proves that the operator ran that business or successfully compromised a target.

The advisory reports 147 engagements. The pinned repository independently contains 147 case-content documents after excluding README/index files, including progress notes. This is a document inventory, not a deduplicated count of organizations or confirmed compromises; the unique-victim total remains unvalidated.

For Israeli capital markets, the advisory distinguishes account-takeover primitives, an unsuccessful or resisted authentication probe, and shared-supplier exposure. The article withholds client identities, personal data and access details. Operator-side records of extraction still require victim-side confirmation before they become verified impact.

The advisory also assesses links to a crypto-gambling settlement channel. Financial motivation is assessed with medium confidence; the separate South Korean operator’s motives should not be imported into the TGSEC attribution. Shared channel references can support an investigative lead, but they do not by themselves establish a data sale, laundering transaction or completed cash-out.

Victim case studies: what the operator sees

A customer-facing integration, a procurement document service and a shared supplier can each expose a route to more sensitive systems. The cases below show what the operator recorded, what made each lead useful and where access was still constrained.

These reconstructions use pinned repository case notes and the advisory’s de-identified procurement and institution records. They describe operator-side accounts rather than victim-confirmed incident findings. Assessed opportunities are identified separately from reported outcomes.

Case 1: A customer-facing integration reveals production trust

In its notes on a customer-facing integration, the repository records an application error disclosing handler source code, hard-coded API credentials and the relationship between a public-facing service and a production API. A companion note reports SQL injection in the same integration. These are operator-side accounts, not independently verified incident findings.

The notes emphasize production credentials, internal service relationships and API request structure. This makes the integration useful as a potential bridge to a more sensitive system, rather than simply a website with an error page. The same source records an important limit: direct external access to the production API was blocked, while some attempted database actions lacked sufficient privileges. Those constraints do not support a claim of unrestricted production access.

Treat customer-facing services and supplier integrations as part of the production trust boundary. Suppress source-code and configuration details in production errors, remove embedded secrets, rotate any disclosed credentials and review the service identities and downstream logs. Preserve network restrictions, while checking that a trusted integration cannot turn exposed credentials into wider access.

Case 2: A procurement document service becomes a map of production trust

The procurement case lesson describes server-side request forgery leading to readable object storage, dozens of configuration files and a credential-to-service map. The advisory also records tender documents and supplier information in the exposed estate. Exact entry points, credential values and target identifiers are withheld here.

The immediate document function is only one part of the value. Configuration material can reveal service relationships and access material for databases, caches, business systems and supplier workflows. Tender documents can add commercially sensitive context. Together, these could let an intruder choose a more valuable next step instead of continuing broad discovery. A mapped credential is not proof that every downstream service was accessed.

Constrain outbound requests from document-processing services and separate their storage permissions from configuration and secrets. After a configuration exposure, revoke and rotate affected credentials according to their reach, and review downstream service logs. Patching the original URL-fetching function alone does not resolve credentials already disclosed.

Case 3: A shared supplier offers reach across organizations

The advisory’s shared-supplier case describes a shared supplier SaaS exposing thousands of personal-data records across multiple entities, production credentials and internal environment references. That is the report’s recorded scope, not an independently reproduced count of unique people or confirmed compromises.

A supplier can provide a concentration of relationships: one application may describe several customers and the connections among them. Personal data could support tailored impersonation, while credentials could create further access opportunities. Internal environment references supply context; they do not themselves grant access. The case illustrates why the supplier relationship matters without establishing that all affected entities were breached.

Enforce tenant authorization on every data read and export, isolate customer secrets, and correlate supplier access with customer-side authentication. If exposure is confirmed, coordinate investigation across the affected tenants and connected credentials instead of treating the supplier’s application as an isolated incident.

Case 4: Persistence meets an authentication boundary that holds

In a separate case, the advisory describes an extended probing effort with no recorded breakthrough through production authentication. The broader material also describes an engagement stopped by WAF enforcement before a mass pull. Those outcomes should remain visible alongside the more severe exposure claims.

A promising lead still requires a usable path. An account or endpoint can justify further investigation without yielding access. Repeated probing suggests effort spent searching for that path; it does not establish successful entry. This case gives defenders a concrete reason to investigate sustained enumeration even when their logs show no successful unauthorized session.

Preserve the successful boundary and address the identified access-control gaps. Correlate repeated authentication and recovery probes across sessions and changing egress, retain the evidence, and check for adjacent paths. The reported outcome supports “no breakthrough recorded,” rather than a claim that the institution had no other exposure.

What connects the cases

The recurring opportunity is a transition in trust: a customer-facing integration to a production service, document processing to internal services, a supplier tenant to another customer, or collected data to a searchable pool. We assess that reusable instructions and persistent memory could reduce repeated discovery work at those transitions. The evidence does not measure how much AI increased success or show autonomous execution of every case.

For an organization assessing its exposure, the useful question is concrete: which identity, service or business relationship becomes reachable if this boundary fails? That answer determines what to monitor, which credentials to contain and who else needs to be involved in the response.

Two attack paths defenders should distinguish

Cloud and identity abuse

Microsoft’s Storm-0940 report describes compromised remote-management supplier application credentials being used through permissions already granted in customer tenants. Interactive user login was not required. Follow-on activity included reconnaissance and application credential changes; some cases reached privileged cloud access in under three hours.

The report separates unsuccessful password spraying (327 accounts across eight organizations) from subsequent application abuse. These are targeting figures, not a compromise count, and successful authentication alone does not establish data theft. Microsoft investigation and hunting guidance

Application discovery, authentication weaknesses and collection

The TGSEC material emphasizes frontend and API discovery, authentication flows, authorization weaknesses, WAF behavior and data retrieval. In an agentic workflow, responses from one step can guide the next test. The defensive question is whether a session or identity progresses from enumeration to unauthorized access and abnormal collection, even when traffic changes source IP.

A framework’s ability to use vulnerability knowledge does not establish a CVE in a particular intrusion. Conversely, the absence of an identified CVE does not make an exposed application safe.

Where to interrupt the procurement chain

The procurement case above crosses several trust boundaries. Each requires its own control and follow-up investigation; fixing the original request-handling flaw does not invalidate credentials already exposed.

Detection and hunting priorities

Apply MFA to user identities and govern workload identities separately. Service principals need constrained permissions, protected credentials and monitoring of application trust. Shared proxy traffic needs session-level correlation; blanket blocking a residential proxy range can affect unrelated users.

For the TGSEC-linked hunt, examine the 23 October worker reference, the 30 October release channel and matching archive artifacts in context. Extend lookback based on the organization’s retention and campaign evidence. An infrastructure hit is an investigative lead, not automatic proof of intrusion.

Authentication and tenant-boundary checks

Hunt for recovery or authentication actions completed without required challenge verification, and cross-tenant reads where the authenticated identity does not match the requested institution. Correlate challenge events with the actual flow policy so SSO, passkeys and trusted-device exceptions do not become false positives.

Downloadable IOCs and artifact scope

The master table consolidates the updated advisory’s explicit indicators with the supporting IOC research and preserved repository observations. It includes full Microsoft application IDs and the nine JPCERT/CC Case E addresses, checked against their primary reports. Japan’s set spans several AI tools and is not attributed to TGSEC. The table is a historical observation set, not a blocklist.

Each public row carries its role, confidence, source context and observation window. Victim-side identifiers, controller access details and unrelated identities are censored; shared services and review leads remain labelled.

Separate attacker-associated infrastructure, shared egress and tool artifacts when importing intelligence. The following indicators have different evidentiary roles.

Primary verification: Microsoft’s application IDs and network indicators · JPCERT/CC Case E source-address list. Network ownership and reputation can change after the reported observation window.

Limits of the binary evidence

The archive manifest records that the five ARTEX release ZIP hashes matched the publisher’s checksum list; it also records a separate toolkit-archive digest. These values align with the captured release metadata. They identify packages, not extracted executables or original authorship.

The reported VirusTotal “no hits” result could not be independently verified from a response record. A missing reputation entry and an analyzed file with zero detections are different outcomes; neither alone establishes a custom build or proves safety.

Distinguishing a fork, private build or repackaged public release requires static comparison of the actual binaries and build metadata in the isolated analysis environment. No archived code, installer or binary has been executed during this work.

Timeline and research basis

Research basis

The findings combine HackersEye’s threat advisory with preserved repository files and commit history, public account and release metadata, supplied portal captures, and the vendor reporting linked throughout this article. Repository code and release binaries were not executed for this analysis.

File counts refer to dated snapshots. Operator notes, test results and interface counters do not establish a verified victim total. Matching repository copies show shared content, not necessarily common control. Victim-identifying details, usable credentials and sensitive access information are censored.

Cover: conceptual AI-generated illustration. Evidence figures are identified in their captions.