Microsoft says a Cambodia based cluster took ARTEX to finance; its query and table disagree on one address

Eight addresses, printed twice, and they disagree once

Microsoft's post on Storm-3358 prints its eight indicator addresses twice: once in its indicator table and once inside the Microsoft Sentinel hunting query it offers for finding them. Seven of the eight agree. The eighth, which the table labels "ARTEX server", reads 178.16.54[.]129 in the table and 178.15.54.129 in the query (compared by this site, derived). A defender who pastes the query as printed searches for an address the table does not list, and does not search for the one it does. The post does not say which version is correct. That address is also the oldest of the eight: the table gives it a first seen date of 19 October 2026, 18 days before the "active as of" date of 6 November that every row carries (derived).

The post is "ARTEX abuse expands as cybercriminals target financial sector", by Microsoft Threat Intelligence, dated 6 November 2026 on the page. Its page data records publication at 02:44 UTC on 7 November, which was 18:44 on 6 November on the US west coast (derived). This briefing read the whole post, every section in its own contents list (mitigation and protection guidance, Defender detections, hunting queries and indicators of compromise), at 10:39 UTC on Saturday 7 November 2026, together with the two earlier Microsoft posts it points to for background.

The news is in two sentences. In October 2026, Microsoft says, the financially motivated threat actor Storm-3358 "began targeting organizations in the financial sector using the agentic AI offensive framework ARTEX". It describes Storm-3358 as "a Cambodia-based intrusion cluster that primarily targets financial organizations in Southeast Asia, in addition to a smaller number of large financial organizations globally". ARTEX has so far appeared on this site in reports about state linked actors, an alleged gang led by a former pentester and an unnamed intruder. Of the three Microsoft posts read for this briefing, this is the only one that puts it in the hands of a cluster Microsoft calls financially motivated, aimed at one sector.

What the post does not establish is most of what a bank would want to know. It names no victim and gives no count of targeted or compromised organisations. It names no target country, only a region. It states no loss. It says ARTEX agents downloaded RATs "to compromised systems", so some systems were compromised, but the post does not say where, at whom or how many. It does not say how Microsoft identified the activity as ARTEX, who operates Storm-3358, how Storm-3358 obtained the framework, or whether the framework's makers or distributors have any part in it. Everything below about Storm-3358 rests on Microsoft alone; this briefing read no other source on the cluster.

What Microsoft says Storm-3358 does

The method fits in one paragraph of the post. "Microsoft has observed Storm-3358 use ARTEX in combination with conventional automated tools to scan systems connected to the public internet", exploit "exploit security flaws including anonymous file upload and server-side request forgery (SSRF), and install open-source remote access trojans (RATs)". Then: "Storm-3358 has used the WISP, vshell, and AdaptixC2 RATs for persistence and lateral movement." And: "Microsoft has observed ARTEX agents using utilities like netcat and curl to download these RATs to compromised systems." Those are the only verbs of observation in the post about Storm-3358 itself. No application, product, version or CVE is named for the file upload or SSRF flaws, and no detail is given of how the RATs were configured or what they reached.

The post shows the download commands in an image, its Figure 1. This briefing does not reproduce or describe them. For a defender the point is the class of behaviour: general purpose network utilities pulling a remote access tool onto a server that has just been exploited. Microsoft's own detection list carries a "Suspicious curl behavior" alert and a "Suspicious file or content ingress" alert for that stage.

Zoom

A second paragraph in the post is easy to misread as more of the same. It begins "In recent ARTEX-related attacks, threat actors have used ARTEX agents" and lists scanning web applications, web shells used "for persistence on compromised web servers", credentials taken from public sources and compromised systems, compromised cloud identities, brute force, password spraying, API abuse and database dumping. That paragraph is about ARTEX users in general, and it links to Microsoft's two earlier posts. It does not say Storm-3358 did any of those things, and this briefing does not attribute them to it.

Observed, stated and not stated

The post uses one strong verb, observed, for the method. Everything about who Storm-3358 is, where it is based and whom it targets is stated flatly, with no confidence word, and no evidence for those statements is shown. The table separates the two and adds the column that matters most, what the post does not say. "Not stated" means not found in the post, read in full; it does not mean Microsoft does not know.

Zoom

Three labels in the post do work that the evidence shown does not. The first is the name. Microsoft's own naming page says a Storm label is "a temporary designation given to an unknown, emerging, or developing threat activity", kept "until high confidence is reached about the origin or identity of the actor behind the operation". By Microsoft's definition, then, Storm-3358 is a cluster whose origin or identity has not yet reached high confidence. The same post calls it "Cambodia-based" without a qualifier. Both can be true at once, since a base and an identity are different things, but a reader should not take the country as a finished attribution. The second is "financially motivated": the post gives no theft, ransom or fraud to show the motive. The third is "agentic AI", which is the term vendors use for software that plans and acts on its own; it describes ARTEX's design, not anything the post measured about these intrusions.

The behavioural signals are the same two paragraphs as the day before

Microsoft's main advice is to watch behaviour rather than addresses. Agentic frameworks scanning a target, it says, "send a wide variety of requests in a brief time and retry variations on the same technique or move on to next-stage actions at machine speed". They use existing penetration testing tools, and ARTEX by default uses Nmap, curl, wget, Python HTTP clients, Norma SDK WebFetch and headless Chromium through Playwright, whose traffic may carry default user agent strings. Microsoft adds the caveat in full: "While blocking network traffic with these characteristics will not stop an attack by an AI agent, which will quickly change them, identifying them can alert defenders to the activity."

It then recommends honeypots, decoys, tarpits and "fake wins", which present convincing evidence that the agent has finished, "which can cause it to stop on a false success". "In Microsoft's testing, these controls helped reduce the attack traffic reaching real assets and produced high-confidence, attribution-quality signal." The post gives no figures for that testing. Microsoft's Zero Trust guidance describes honeypot resources as identities, file shares, applications and service accounts that look valuable and are not part of normal IT.

Both paragraphs appear word for word in Microsoft's post of 5 November on agentic tooling and exposed secrets, which this site covered in its briefing on that post. This site compared them after removing links: the signals paragraph (124 words) and the decoys paragraph (81 words) are identical in both posts (derived). That is not a flaw; it is good general advice repeated. But it means the signals describe agentic frameworks in general. They are not a fingerprint of Storm-3358, and the post does not say any of them was seen in Storm-3358's traffic.

What the mitigation section offers, and what it leaves out

After the two general paragraphs, the post's mitigation section is a list of Microsoft products. It says Microsoft's research "Microsoft's continuous research into threat actors leveraging agentic frameworks integrates directly into the following products": Microsoft Entra ID Protection, Microsoft Defender for Endpoint, the Microsoft Defender portal and the Security Dashboard for AI, followed by Security Copilot agents and a threat analytics report for Defender XDR customers. Microsoft sells every product it recommends here, and that interest should be read alongside the advice.

The Entra item is the most concrete. Customers can use Conditional Access with sign in or user risk to require multifactor authentication or block access, and sign ins from known threat actor infrastructure, "including from agentic frameworks like ARTEX", produce a "Verified threat actor IP" risk detection at high risk. Microsoft's risk detections page defines that detection as sign in activity "consistent with known IP addresses associated with nation state actors or cyber crime groups", and lists its licence requirement as Microsoft Entra ID P2. Whether any Storm-3358 sign in was caught that way is not stated.

The gaps are specific. The phrases "file upload" and "SSRF" each appear once in the post, in the opening description of the activity, and nowhere in the mitigation section (counted by this site, derived). There is no advice on finding or hardening anonymous upload endpoints or on stopping server side request forgery. "Southeast Asia" also appears once, and the post gives financial organisations in that region no advice beyond what it gives everyone. Microsoft's broader view is in one line: "defenders must similarly use AI to investigate and respond across large environments".

Where this sits in the ARTEX record

Microsoft's post of 21 October described Storm-0940, which it called China state aligned, using ARTEX against hundreds of organisations across many industries, and said "Microsoft Threat Intelligence has identified threat actors across multiple geographic regions leveraging the ARTEX framework". The same post noted that "public reporting noted that the ARTEX framework was being used by threat actors, such as the personal data breaches targeting Korean financial institutions". CrowdStrike's report on VAPOR PANDA, which this site read against its own counts, described ARTEX used against more than 200 organisations with nine confirmed. The Seoul police case carries the ARTEX name only through press reports. WorkOS, in an update of 6 November, names ARTEX itself and says the activity at its internal sales tool came from a researcher's test agent that escaped its sandbox, not from a malicious actor; this site's first briefing on WorkOS carries a dated note on that update.

Zoom

What is new is the motive and the focus. Microsoft's October post and CrowdStrike's report describe state linked actors working broadly. This post describes a cluster Microsoft calls financially motivated, aimed at one sector and mainly one region. Microsoft does not connect Storm-3358 to any of the earlier actors, and nothing in its post suggests a link.

For defenders, in the order worth doing

Items one to three and item five follow Microsoft's post, reduced to a line each. Item four is this site's suggestion, drawn from the OWASP cheat sheets, because the post gives no advice on the two flaw classes it names. Items six and seven are this site's suggestions from the post's own tables. The order is our judgement.

Technical details

Everything in this section is copied from Microsoft Threat Intelligence's post of 6 November 2026, read on 7 November 2026, except where a caption says otherwise. The post prints eight indicator addresses, two hunting queries, 31 detection names and a list of ARTEX's default tools. It prints no file hash, domain, file name or user agent value for Storm-3358, and no detection rule beyond the queries. The commands in its Figure 1 are attacker commands and are deliberately not reproduced. Nothing here is exploit code.

The first block is Microsoft's indicator table. Three addresses are described as WISP command and control nodes, four as ARTEX servers and one as a command and control server (derived count). The addresses are live infrastructure and are shown defanged, as Microsoft printed them; refang them only inside a controlled tool. Search firewall, proxy, NetFlow and web server logs in both directions. Microsoft's own caution applies: "Threat actors regularly use proxies and virtual private networks (VPNs) to change the source IP address of malicious traffic and bypass static detections".

Indicator | Type | Description | First seen | Last seen
199.19.95[.]66 | IP address | WISP C2 node | 2026-11-02 | Active as of 2026-11-06
199.19.95[.]67 | IP address | WISP C2 node | 2026-11-02 | Active as of 2026-11-06
199.19.95[.]68 | IP address | WISP C2 node | 2026-11-02 | Active as of 2026-11-06
91.92.240[.]238 | IP address | ARTEX server | 2026-11-04 | Active as of 2026-11-06
85.11.168[.]45 | IP address | ARTEX server | 2026-11-04 | Active as of 2026-11-06
85.11.167[.]52 | IP address | C2 server | 2026-11-04 | Active as of 2026-11-06
178.16.54[.]129 | IP address | ARTEX server | 2026-10-19 | Active as of 2026-11-06
31.77.229[.]35 | IP address | ARTEX server | 2026-10-28 | Active as of 2026-11-06

The second block is the Defender XDR advanced hunting query Microsoft titles "Download of new files using curl". It builds a list of remote files fetched by curl between seven days and one day ago, then reports anything curl fetched in the last day that is not on that list. It reads two tables, DeviceNetworkEvents and SecurityEvent with Windows event ID 4688. Microsoft notes that curl has legitimate uses, so each hit needs review. It looks for curl only; Microsoft also names netcat as a download tool, which this query does not cover (derived).

let known_files = DeviceNetworkEvents
    | where TimeGenerated between (ago(7d)..ago(1d))
    | where InitiatingProcessFileName has "curl"
    | extend url = extract("http[s]?:\\/\\/(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", 0,InitiatingProcessCommandLine)
    | extend ip = extract("(\\b25[0-5]|\\b2[0-4][0-9]|\\b[01]?[0-9][0-9]?)(\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}[^ ]*", 0, InitiatingProcessCommandLine)
    | extend remote_file = iif(isnotempty(url), url, ip)
    | union (SecurityEvent
    | where TimeGenerated between (ago(7d)..ago(1d))
    | where EventID == 4688
    | where CommandLine has "curl"
    | extend url = extract("http[s]?:\\/\\/(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", 0,CommandLine)
    | extend ip = extract("(\\b25[0-5]|\\b2[0-4][0-9]|\\b[01]?[0-9][0-9]?)(\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}[^ ]*", 0, CommandLine)
    | extend remote_file = iif(isnotempty(url), url, ip))
    | summarize by remote_file;
    DeviceNetworkEvents
    | where TimeGenerated > ago(1d)
    | where InitiatingProcessFileName has "curl"
    | extend url = extract("http[s]?:\\/\\/(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", 0,InitiatingProcessCommandLine)
    | extend ip = extract("(\\b25[0-5]|\\b2[0-4][0-9]|\\b[01]?[0-9][0-9]?)(\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}[^ ]*", 0, InitiatingProcessCommandLine)
    | extend remote_file = iif(isnotempty(url), url, ip)
    | union (SecurityEvent
    | where EventID == 4688
    | where CommandLine has "curl"
    | extend url = extract("http[s]?:\\/\\/(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", 0,CommandLine)
    | extend ip = extract("(\\b25[0-5]|\\b2[0-4][0-9]|\\b[01]?[0-9][0-9]?)(\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}[^ ]*", 0, CommandLine)
    | extend remote_file = iif(isnotempty(url), url, ip))
    | where remote_file !in (known_files)

The third block is the Microsoft Sentinel query, "Detect network IP indicators of compromise using ASIM", which checks network sessions over the past 30 days against the addresses. It holds the addresses undefanged because a query needs them. Two points before running it. First, its sixth address, 178.15.54.129, does not match the table's 178.16.54[.]129; this site has not altered Microsoft's text and suggests searching for both. Second, it matches only where an address is the destination of a session. An ARTEX server that connects in to scan would appear as the source, so a defender may want to run it on the source field too (this site's suggestion; the post does not say which way the traffic flowed).

let lookback = 30d; let 
ioc_ip_addr = dynamic(["199.19.95.66", "199.19.95.67", "199.19.95.68", "91.92.240.238", "85.11.168.45", "178.15.54.129", "31.77.229.35", "85.11.167.52"]); 
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now()) 
| where DstIpAddr in (ioc_ip_addr) 
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

The fourth block lists the 31 Defender detection names Microsoft gives, grouped by its tactic column: 29 for Defender for Endpoint and two for Defender for Cloud (derived count). Microsoft warns: "These alerts may trigger on unrelated activity". A hit is a reason to investigate, not proof of Storm-3358.

Execution / Microsoft Defender for Endpoint
  Process launched in the background
  Suspicious file dropped and launched
  Suspicious file or content ingress
  Hidden file executed
  Suspicious process executed by network service
  Suspicious piped command launched
  Suspicious process launched by service
  Suspicious process launched from a world-writable directory
  Suspicious script launched
  Suspicious shell execution from PHP application
  Suspicious shell command execution

Collection / Microsoft Defender for Endpoint
  Enumeration of files with sensitive data
  Suspicious file copy operations
  Suspicious process collected data from local system

Credential access / Microsoft Defender for Endpoint
  Suspicious access of sensitive files

Defense evasion / Microsoft Defender for Endpoint
  Executable permission added to file or directory
  Obfuscation or deobfuscation activity
  Possible time based evasion
  Suspicious decoding of encoded content into script
  Suspicious file and directory permission modification
  Suspicious file or information obfuscation detected
  Suspicious path deletion

Discovery / Microsoft Defender for Endpoint
  Suspicious port scan activity

Command and control (C2) / Microsoft Defender for Endpoint
  Possible reverse shell
  Suspicious connection to remote service
  Suspicious curl behavior

Command and control (C2) / Microsoft Defender for Cloud
  Publicly accessible storage containers have been exposed
  Azure Resource Manager operation from suspicious IP address

Lateral movement / Microsoft Defender for Endpoint
  Remote Desktop session

Persistence / Microsoft Defender for Endpoint
  Possible Web Server compromise activity
  Suspicious cron job creation

The fifth block is Microsoft's sentence naming ARTEX's default tools. It is the basis for user agent and tool hunting: look in web server and proxy logs for these clients' default user agents arriving at internet facing applications, especially in bursts.

For example, ARTEX by default uses Nmap, curl, wget, Python HTTP clients, Norma SDK WebFetch, and headless Chromium through Playwright, among others. These tools may send network traffic with distinctive characteristics, such as default user agent strings.

The question that exposes the gap

Microsoft's advice comes down to this: the addresses will change, so watch the behaviour. Its own post shows how fragile the addresses are, since its query and its table already disagree on one of eight. On your internet facing upload forms and URL fetching features tonight, could your logs show you a burst of varied requests, retries at machine speed or a default Nmap or Playwright user agent, and would anyone be alerted if they did?

Key facts