artex-storm-3358-cover

ARTEX Reaches the Financial Sector: What Storm-3358’s Agentic Attacks Look Like in the Cloud

November 08, 2026

ARTEX Reaches the Financial Sector: What Storm-3358’s Agentic Attacks Look Like in the Cloud

Book a Demo

A financially motivated actor that Microsoft tracks as Storm-3358 is now running the ARTEX agentic attack framework against banks and other financial organizations. What we found in the public record: the techniques are not new, the tooling is noisy, and in cloud workloads the most useful signal is not an IP address but a web process that suddenly starts downloading and running binaries.

TL;DR

On 6 November 2026, Microsoft reported that Storm-3358, a Cambodia-based intrusion cluster, began using ARTEX against the financial sector in October. Its targets are mainly in Southeast Asia, plus a smaller number of large financial organizations globally. ARTEX is an open-source agentic penetration testing framework first released on GitHub in July 2026. It is the latest of several ARTEX campaigns made public since October, spanning espionage groups, criminal crews and now financially motivated operators.

  • Nothing in the attack chain is new. Storm-3358 scans internet-facing systems, exploits anonymous file upload and server-side request forgery (SSRF), and installs open-source remote access trojans (RATs).
  • The payloads are off-the-shelf. The RATs are WISP, vshell and AdaptixC2, pulled down by ARTEX agents with curl and netcat.
  • ARTEX is a harness, not a model. It wraps whatever language model the operator plugs in. Blocking one AI vendor does not stop it.
  • Agents are fast but loud. Bursts of retries, default tool user agents and ARTEX’s own name left in artifacts. IP lists go stale in days; this behavior does not.
  • In the cloud, the strongest signal is a web-serving process spawning curl or nc. That is where file upload, SSRF and RAT delivery meet.

How does the attack start?

With ordinary web application flaws. Microsoft observed Storm-3358 combine ARTEX with conventional automated scanners to find systems exposed to the internet. The agents then exploit two bug classes:

  • Anonymous file upload. An upload endpoint that does not check who is uploading or what. It is the classic path to a web shell.
  • SSRF. A flaw that lets the attacker make the server send requests on its behalf, often to internal addresses it should never reach.

What happens after access?

The agents install a RAT and move on. ARTEX agents use curl and netcat to download WISP, vshell or AdaptixC2 onto the compromised host (Ingress Tool Transfer, T1105). Storm-3358 uses these for persistence and lateral movement.

ARTEX can also spray passwords, abuse APIs and dump databases, reusing each foothold at machine speed.

The practical takeaway: the gap between first exploit and a running implant is short, so detection has to happen on the workload, not in a weekly review.

Is this a new kind of attack?

No. It is a faster version of an old one. The claims circulating about ARTEX, checked one by one:

  • “AI agents invented new attack techniques.” False. Upload flaws, SSRF, curl and open-source RATs are all long documented.
  • “This is fully autonomous hacking.” Not shown. In other ARTEX campaigns, human operators still steered the agents at key decision points. Microsoft does not describe Storm-3358 running without an operator.
  • “Block the model provider and you stop it.” No. ARTEX works with Anthropic, OpenAI or any OpenAI-compatible endpoint. Swapping models is a config change.
  • “The repo is gone, so the threat is over.” No. The original GitHub repository was taken down in October, but forks keep circulating. Censys counted 1,465 hosts running an exposed ARTEX console on 4 November.
  • “Block the published IPs and you are safe.” Partly. Microsoft itself warns that operators rotate addresses through proxies and VPNs. The IPs help you look back, not forward.

Where does this show up in a cloud workload?

At runtime, on the web-facing workload, as a short chain of unusual events. Each step alone may be noise. Together they tell a clear story.

  • A new executable file written by the web server. A file upload flaw usually lands a script or binary in a directory the web process can write to.
  • A web-serving process spawning a shell, then curl, wget or nc. Web servers and application runtimes rarely need to fetch and run binaries. This is the RAT delivery step.
  • A new binary executed from a temp or world-writable path. Freshly downloaded RATs tend to run from where they were dropped.
  • Outbound connections to infrastructure the workload has never talked to. This is the RAT calling home.
  • New cron entries. A common way to keep the implant alive after reboot.
  • Requests from the workload to the cloud instance metadata service. In cloud environments, SSRF can reach the metadata endpoint and expose instance credentials. Microsoft does not say Storm-3358 did this. It is the reason SSRF matters more in the cloud than on premises.

At the edge, watch for bursts of varied requests from one source, repeated retries, and default user agents from tools ARTEX uses, such as Nmap, curl, wget and headless Chromium. Blocking them won’t stop an agent, but spotting them tells you one is at work.

Indicators of Compromise

Microsoft lists these as active as of 6 November. Treat them as hunting leads, not a blocklist. A match on an ARTEX server means probing or exploitation attempts. A match on a C2 node from inside your environment means a likely implant.

  • WISP C2 nodes: 199.19.95[.]66, 199.19.95[.]67, 199.19.95[.]68 (first seen 2 November)
  • ARTEX servers: 91.92.240[.]238, 85.11.168[.]45 (first seen 4 November), 31.77.229[.]35 (first seen 28 October)
  • C2 server: 85.11.167[.]52 (first seen 4 November)

Microsoft lists one more ARTEX server address, but its IOC table and its own hunting query give two different values for it. We have left it out rather than publish the wrong one.

What should security teams do now?

  • Find your internet-facing upload endpoints and lock them down. Require authentication, restrict file types, and store uploads outside the web root with execution disabled.
  • Fix or contain SSRF, and enforce IMDSv2. On AWS, requiring session tokens for the metadata service blocks the simplest SSRF credential theft.
  • Hunt for web processes that spawn curl, wget or nc, plus new cron jobs and new executables on web-facing hosts, back to the start of October.
  • Check egress logs against the IOCs above. Any internal host talking to the C2 addresses should be treated as compromised.
  • Restrict outbound traffic from web workloads. A web server that cannot reach the internet cannot fetch a RAT.
  • Consider decoys. In Microsoft’s testing, honeypots, tarpits and fake wins pulled agent traffic away from real assets.

How can Upwind help?

ARTEX makes intrusion faster, but it does not make it invisible. Every step of this chain happens at runtime: a file written by a web process, a shell spawned from it, a download, a new binary, a new outbound connection. Upwind’s runtime sensor follows process lineage and network activity on cloud workloads and Kubernetes nodes, so the full chain shows up as one story rather than five separate alerts.

Upwind also maps which workloads are exposed to the internet and which hold cloud credentials, so you can fix the upload and SSRF paths that matter first.

To learn more about how Upwind detects post-exploitation activity on cloud workloads at runtime, schedule a demo.

Demo the Upwind Platform

See how Upwind is reducing risk and strengthening cloud security for global enterprises.
Get a Demo
Contents
Add the Upwind RSS Feed to Slack
Connect the Upwind RSS Feed to your Slack.
Follow the how-to here.
Threat RSS
Add the Upwind RSS Feed to Slack
Connect the Upwind RSS Feed to your Slack.
Follow the how-to here.
Main RSS