Iron Man & YamStore: Powering a Global Phishing-as-a-Service Ecosystem

1. Executive Summary

Resecurity identified and mapped the infrastructure supporting a commercial phishing-kit-as-a-service (PhaaS) operation marketed under the name “Iron Man System.” The kit is sold to criminal buyers as a self-hosted package that deploys pre-built lure pages impersonating postal and courier services, toll and traffic-fine authorities, tax agencies, banks, telecoms and loyalty programmes, then captures the data victims submit. 

Leveraging human intelligence (HUMINT), Resecurity acquired a license to trace the back-end infrastructure, code repository, related build pipeline, and operator identifiers. Our HUNTER team successfully infiltrated communities managed by Chinese threat actors to gain additional insights into the group behind the kit and its associates.

Resecurity gained access to Iron Man’s infrastructure and found 2,360 phishing templates impersonating banks, retailers, healthcare providers, transportation authorities, police departments and government agencies across 130 countries. 

Working closely with Microsoft, the lead in this operation, and other industry partners, the cybercriminal infrastructure managed by Chinese threat actors has been mapped and targeted. Microsoft’s Digital Crimes Unit (DCU) facilitated a disruption of the ecosystem’s primary developers and infrastructure.

This report documents what Resecurity confirmed: a cluster of domains providing licensing, telemetry and object storage services, a self-hosted build registry exposing the vendor’s development history and a partial list of registered operator accounts, and a template catalog of 2,360 distinct phishing lure packages spanning 130 target regions. Findings are presented with supporting exhibits (redacted where they would otherwise expose working credentials or live attack infrastructure). Operational detail about how the kit is installed or licensed, and any credential values, have been deliberately omitted from this report; they do not change the attribution or defensive picture and their inclusion would carry unacceptable misuse risk.

The operation is run by a persistent and organised group operating a single shared infrastructure cluster and an actively maintained build pipeline. The most recent catalog addition is dated 1 October 2026 and the most recent build-registry publication is dated within the week of this report, indicating ongoing operation and active sales. A coordinated takedown of the licensing host and the registry, combined with sinkholing of the storage domain, would disrupt the operation for its full buyer base simultaneously rather than one deployment at a time.

2. Key Findings

3. Tradecraft Overview

“Iron Man System” presents itself to buyers as a self-hosted admin panel with a bilingual (Chinese/English) interface for managing deployed phishing “frontends” — individually configured lure-page instances, each bound to an impersonated brand and a hidden admin URL path. Resecurity’s lab deployment showed a panel named “Iron Man System,” version 6.3.1, with a license countdown and a frontend list populated with lure instances impersonating a European parking-fine operator and a Japanese payment service. The infrastructure also contains a separate installation/bootstrap web console that buyers use to provision a deployment.

EXHIBIT A — VENDOR INSTALLATION/BOOTSTRAP CONSOLE

EXHIBIT B — LAB DEPLOYMENT, FRONTEND MANAGEMENT VIEW

4. Licensing and Authorization Backend

Resecurity confirmed the kit’s license/authorization host through two independent methods: a filtered packet capture of outbound traffic from the live lab deployment, and static review of configuration artifacts recovered from the vendor’s own build registry (Section 5). Both methods converge on the same host. A separate, differently-named host found in one historical build’s shipped configuration was tested and found to be an inactive legacy value rather than the live authorization backend; this is noted for the record and should not be relied on as an active IOC.

The panel in Resecurity’s lab polled its own local license-status endpoint approximately every twenty seconds using a vendor-issued license key; that local call in turn triggered the server-side request to the authorization host identified above. This confirms the panel cannot operate without regular contact with vendor infrastructure — a dependency that favors defenders, since disabling or sinkholing the authorization host would degrade every active deployment, not just the one under investigation.

5. Build Registry and Operator Cluster

Resecurity located a self-hosted Git and container-registry server operated by the same group, reachable at two domains sharing infrastructure. Browsing the registry’s public package listing without authentication, Resecurity found an organisation account whose name and repository match the deployed kit, confirming this registry is the group’s own build and distribution infrastructure rather than a third-party mirror. The registry’s package page showed 911 published image versions, with publication timestamps spanning at least mid-July through late-July 2026 in the sample reviewed, and a most-recent publication dated within days of this report— evidence of an actively maintained pipeline rather than a dormant or abandoned project.

EXHIBIT C — BUILD REGISTRY, PACKAGE DETAIL

EXHIBIT D — BUILD REGISTRY, VERSION HISTORY

The registry’s public user directory, accessible without authentication, lists eight registered accounts. Account creation dates span from October 2025 through June 2026, indicating the operator cluster has been active for at least a year and has continued to add accounts (likely developers or resellers) through the current reporting period. This table is reproduced from the registry’s own public listing; Resecurity did not attempt to access any account.

The “admin” account — the publisher of the current image — is the only account whose email domain (aidchildren) matches one of the cluster’s own hostnames, consistent with it being the core operator account rather than a reseller or buyer account. The remaining accounts use free webmail providers (QQ, Gmail, ProtonMail), typical of operators seeking to minimise attribution.

6. Shipped Configuration and Storage Backend

Resecurity reviewed a build configuration artifact shipped inside one of the registry’s published container images. The configuration file confirms the kit is built to use an S3-compatible object-storage backend for uploaded/captured content, pointed at a vendor-controlled storage domain fronted by a CDN/reverse-proxy service.

EXHIBIT E — SHIPPED BUILD CONFIGURATION (REDACTED)

7. Storage Contents — Relation to the Kit

The object-storage endpoint identified in Section 6 (ossapi[.]haoeryu[.]top) was found to hold a substantial volume of stored objects. Resecurity re-examined the panel’s own compiled binary — already obtained during the registry/build analysis in Section 5 — for a direct mechanism linking the kit to this kind of stored content. That analysis establishes a confirmed, code-level link, set out below.

▪ Confirmed — the kit ships a dedicated goods-catalog and image-upload subsystem

The binary contains a complete, independently addressable controller for a "remote goods" catalog (internal package path devops-super/internal/controller/remotegoods), exposing the API routes. These routes import a goods catalog per target country, list it for rendering, and — critically — retry and upload the catalog’s product images to a media backend through a dedicated endpoint. Internal logging strings compiled into the same binary ("goods stat upload media failed," "goods stat local media missing, skip upload," "goods stat media uploaded: %s -> %s," "goods stat meta image upload incomplete, will retry next report") confirm this upload path is a live, monitored subsystem with its own retry and failure handling — not inert or unused code.

▪ Confirmed — captured victim records store a goods selection alongside payment data

The same binary contains the kit’s own reporting queries over its victim-submission table, which read a field named "SelectGoods" (with a "title") out of each captured record’s JSON content, in the same query that counts how many records also contain "cardData.cardNumber". A separate, template-facing field list recovered from the binary includes goods_data, goods_name and goods_price positioned alongside card_number, expiry_date, verify_code and client_info — the same submission schema used by the card-capture step. 

8. Template Catalog Assessment

Resecurity obtained a structured catalog of the kit’s phishing lure templates (2,360 entries, snapshot through 1 October 2026) together with size and download-status metadata for 1,566 of those entries (a combined 17.4 GB corpus of packaged lure-page bundles). 

This section presents catalog-level statistics:

Courier/postal-service impersonation is the single largest template category by impersonated-brand count, followed by government tax-authority and banking impersonation. This mix is consistent with mass-market, high-volume smishing/phishing campaigns rather than targeted business-email-compromise use.

Catalog growth accelerated sharply in May 2026 (322 new/updated templates in a single month) and has remained elevated through the most recent full month captured, indicating sustained investment in content production rather than a one-time catalog build-out. Resecurity separately observed, via the vendor’s own live template-listing interface, entries dated as recently as 1 October 2026, confirming the catalog remains in active production at the time of this report.

9. Infrastructure Cluster Summary

The domains identified across this investigation resolve to a consistent set of hosting and DNS patterns, and functional roles cluster cleanly into licensing, telemetry, storage and build-infrastructure categories — consistent with a single operator running all five domain families rather than independent, unrelated services.

10. Cybercriminal Infrastructure

Indicators are defanged in accordance with standard CTI handling practice. IP addresses are current as of the telemetry capture window; operators of this kit were rotating fronting infrastructure periodically leveraging domain names registered by the end users (customers of the group behind "Iron Man", previously responsible for development of other kits under different branding).

Note. Several IOCs resolve behind a CDN/reverse-proxy service; the listed IP addresses represent the fronting service observed at capture time, not necessarily the operator’s origin infrastructure.

11. Impact and Risk Assessment

12. Methodology and Limitations

Findings in this report are based on: a purchased license and an isolated lab deployment of the kit operated solely for defensive research; a filtered packet capture of outbound network traffic from that lab deployment; unauthenticated browsing of the operator’s publicly exposed build-registry package pages and user directory; and a structured template catalog with associated metadata. No production victim systems, live buyer deployments, or third-party infrastructure were accessed or tested. Recovered credentials were not tested or used for any purpose beyond confirming their presence in shipped configuration. This report deliberately omits step-by-step installation and licensing mechanics and all credential values; their inclusion would not change the attribution or defensive conclusions presented here and would carry an unacceptable risk of facilitating misuse.

About Resecurity / Disclaimer

Resecurity is a global cybersecurity company providing cyber threat intelligence, digital forensics and risk-management solutions. This report is provided for situational awareness and defensive purposes only. Information herein reflects Resecurity’s analysis as of the date of issue and may not reflect subsequent changes to the threat actor’s infrastructure or operations. Indicators are defanged and certain operational detail and credential values have been deliberately withheld or redacted to prevent misuse.