OT Threat Hunter Series
AZURITE
The long-dwell OT data-theft actor shares overlap with Flax Typhoon.
AZURITE is easy to miss because the activity looks like business as usual. The group does not deploy obvious malware, does not cause immediate operational impact, and does not announce itself with political messaging on an HMI. It logs into engineering workstations, uses the software already installed there, reads and stages files, and leaves. The data it takes is not random. It is the operational documentation that lets a future attack be precise instead of blind.
Think of AZURITE as the surveying team that walks a building before a heist. They take measurements, photograph rooms, note the alarm panel, watch the staff routine. Nothing they do is dangerous on its own. What they collect makes the eventual operation faster, surer, and harder to interrupt. AZURITE is doing that surveying across manufacturing, defense, automotive, electric, oil and gas, pharmaceutical, and government environments.
This report covers what AZURITE has been observed doing, the engineering workstation and supervisory layer techniques you would actually see in telemetry, and the hunts that surface them. The audience is an OT threat hunter, detection engineer, or security lead at any organization where the operational data is itself the crown jewel.
AZURITE is a new designation, added in Dragos's 2026 Year in Review alongside SYLVANITE and PYROXENE. That brings the tracked set to 26 groups, 11 of which were active during 2025.
The group shares technical overlap with Flax Typhoon, a China-nexus actor tracked across the broader intelligence community, and with Ethereal Panda, UNC5923, Raptor Train, and Red Dev 54. Dragos tracks AZURITE separately because the OT data theft tradecraft is distinctive enough to warrant it, even though the affiliations point back into the same operational ecosystem. Worth keeping in mind that overlap is not attribution. Two groups sharing tooling or infrastructure does not make them the same team.
One of the more useful findings in the 2026 report is that this activity is best read as a coordinated ecosystem with a division of labor rather than one group doing everything. Three of those roles matter for this hunt.
Rapidly weaponizes vulnerabilities in internet-facing systems, then hands the foothold off. Dragos observed it exploiting Ivanti VPN vulnerabilities within 48 hours of public disclosure, dropping web shells on F5 appliances, and pulling Active Directory credentials before passing access along.
Overlaps Volt Typhoon. Known for long-term access inside US critical infrastructure and for stealing OT data with an eye toward manipulating OT systems. SYLVANITE has been observed handing footholds directly to VOLTZITE, sometimes within days.
Also Stage 2, but its observed behavior stops at gathering. It reaches the engineering workstation, takes the documentation, and does not touch the process.
The practical implication is that stopping the initial compromise does not eliminate the risk, because another group may inherit the access. It also means a confirmed finding on one of these groups is a good reason to go hunt the other two.
Treat the sector list as a floor rather than a ceiling. Any environment where engineering workstations hold current process documentation is a viable target, and that is most environments. Geographically, activity spans the United States, Europe, Australia, Japan, South Korea, and Taiwan.
The observed path into OT is unglamorous and repeatable. AZURITE exploits a vulnerability or uses compromised credentials against an internet-facing remote access system, drops a web shell on the exploited VPN appliance for durable access, then works inward. Traffic arrives from adversary-controlled IPs fronted by proxy infrastructure built on compromised SOHO routers across multiple countries. From the IT foothold, the group tunnels with SOCKS, pivots through a jump server into the OT network, and lands on an engineering workstation.
Two things about that path are worth sitting with. First, none of it requires an ICS-specific exploit. It is edge device exploitation, credential reuse, and tunneling, all techniques your IT security team already recognizes. Second, the SOHO proxy layer means the far end often looks like residential broadband rather than a hosting provider or a known bad IP. Reputation-based blocking is not going to help much here.
The defining behavior is persistence measured in months. The group is quiet by design, and the reporting is consistent with an actor that is not tripping the alerts most programs are tuned for.
Our assessment, not documented fact
Access to the OT network is probably not a daily occurrence. The collection is persistent, but the sessions are likely infrequent and short. That is an awkward shape for detection. A hunt scoped to the last seven days can land in a gap between visits and come back clean while the actor is still resident. It is one of the main reasons we push a longer hunt cycle for AZURITE than for the other actors in this series.
The exfiltrated data set in public reporting includes OT network diagrams, alarm data, PLC configurations, HMI data, and process information. That is exactly the set that turns a generic ICS attack into a targeted one.
What makes this hard to catch is that AZURITE works interactively on the workstation using software already installed there. There is no dropped toolkit to find. The engineering software is doing what engineering software does, just for the wrong person.
Dragos links AZURITE with moderate confidence to Flax Typhoon, Ethereal Panda, UNC5923, Raptor Train, and Red Dev 54, with some reported links to VOLTZITE. Flax Typhoon has been documented mostly in IT environments, so AZURITE's OT focus reads as a maturation of the broader cluster's industrial targeting rather than something entirely new. The Raptor Train overlap is the one to note operationally, since that cluster is known for SOHO and IoT device botnets, which lines up with the proxy infrastructure described above.
For hunting purposes, the moderate confidence label matters. Build hunts around the behavior, not the name. If you go looking specifically for Flax Typhoon indicators you will miss AZURITE activity that does not carry them.
AZURITE techniques are mostly quiet ones, and the group blends into normal engineering activity by design. The hunting problem is not spotting unusual tools or obvious malware. It is spotting normal-looking activity performed by the wrong account, from the wrong host, or at the wrong time. That puts the burden on knowing your environment: who legitimately touches engineering data, from where, how often, and using what.
| Technique | ID | AZURITE behavior | Where to hunt |
|---|---|---|---|
| Exploit Public-Facing Application | T1190 | Exploitation of internet-facing VPN and remote access appliances for initial access | Appliance logs, patch-to-exploit lag on VPN and remote access gear |
| Server Software Component: Web Shell | T1505.003 | Web shell dropped on the exploited appliance for durable access | Appliance file integrity monitoring, requests to paths not part of the product |
| Proxy: External Proxy | T1090.002 | Traffic fronted by proxy infrastructure built on compromised SOHO routers | Outbound sessions from OT-adjacent hosts to residential and consumer ASN space |
| Proxy: Internal Proxy | T1090.001 | SOCKS tunneling from the IT foothold through a jump server into OT | Long-lived sessions to jump hosts, non-standard ports on IT-to-OT paths |
| Valid Accounts | T1078 | Long-dwell use of legitimate credentials rather than malware | Authentication logs, session duration analysis |
| System Binary Proxy Execution | T1218 | Native and signed tooling driven interactively on engineering workstations | Process ancestry, signed binaries launched from unusual parents |
| Data from Local System | T1005 | Engineering project files, diagrams, and configuration exports read off the workstation | File access auditing on engineering directories, meaning SACLs plus Event ID 4663 |
| Data from Information Repositories | T0811 | Historian queries pulling tag-enriched process history | Historian query logs, database audit |
| Program Upload | T0845 | Controller logic and configuration retrieved from PLCs | Engineering protocol traffic, upload function codes |
| Screen Capture | T0852 | HMI displays captured as images | Screenshot tooling execution, image files in user profiles |
| Remote System Information Discovery | T0888 | Process and asset enumeration across the OT network | OT protocol traffic analysis |
| Archive Collected Data | T1560 | Engineering data staged into ZIP, RAR, 7z, or split archives | Anomalous archive creation on engineering hosts |
| Exfiltration Over C2 Channel | T1041 | Slow, low-volume outbound over the established tunnel | Cumulative outbound volume analysis against baseline |
| Exfiltration Over Web Service | T1567 | Consumer cloud storage used as the exfiltration endpoint | Outbound to OneDrive, Google Drive, Dropbox, MEGA from OT-adjacent hosts |
| Create or Modify System Process | T1543 | Service-based persistence sitting unnoticed for months | Service creation events and service auditing on engineering workstations |
| Boot or Logon Autostart Execution | T1547 | Run key and startup folder persistence | Run key auditing on engineering workstations |
| Scheduled Task/Job | T1053 | Scheduled task persistence | Task scheduler auditing |
| Event Triggered Execution | T1546 | WMI event subscription persistence | WMI subscription auditing |
Network detection for AZURITE is mostly about cumulative anomaly over time rather than any single high-confidence signal. The traffic is quiet, so the hunt has to add up small signals across a long window.
A note before you run these. The queries below are written to be syntactically valid and to point at the right data sources, but they have not been executed against a production data set. Field names vary by sourcetype, by CIM normalization, and by how your forwarders are configured. Treat them as logic to adapt rather than as copy-paste detections. If you want to validate them, the cheapest path is a lab instance with replayed PCAP and synthesized Windows events, checked both for true positives against known test activity and for false positive volume across a normal week.
One correction worth calling out
Sysmon Event ID 11 is FileCreate. It will not show you file reads. Hunting read access to engineering directories requires SACLs on those directories plus Windows Security Event ID 4663 with success auditing enabled for file system objects. The queries below reflect that, and the visibility prerequisites in Section 8 call it out explicitly.
Splunk Cumulative outbound volume from OT-adjacent hosts
index=netflow src_ip IN (ot_adjacent_hosts)
NOT dest_ip IN (internal_ranges)
NOT dest_ip IN (documented_external_destinations)
| bin _time span=30d
| stats sum(bytes_out) AS total_out BY src_ip, _time
| eventstats avg(total_out) AS avg_out, stdev(total_out) AS sd_out BY src_ip
| where total_out > (avg_out + (2 * sd_out))
| eval month=strftime(_time, "%Y-%m")
| table month, src_ip, total_out, avg_out
| sort - total_outThis baselines each host against its own history, so it needs at least six monthly buckets before the standard deviation carries any weight. That is where the 90 day minimum retention in Section 8 comes from, and a full year is better.
Splunk Archive creation followed by an outbound spike
index=sysmon EventCode=11 host IN (ews-*, eng-*)
TargetFilename IN ("*.zip", "*.rar", "*.7z", "*.tar.gz", "*.7z.0*", "*.r0*")
| stats min(_time) AS archive_time, values(TargetFilename) AS archives BY host
| join type=inner host
[ search index=netflow src_ip IN (ews-*, eng-*)
| rename src_ip AS host
| stats sum(bytes_out) AS outbound_bytes, max(_time) AS last_out BY host ]
| where outbound_bytes > 100000000 AND last_out > archive_time
| eval archive_time=strftime(archive_time, "%F %T"),
last_out=strftime(last_out, "%F %T")
| table host, archive_time, archives, last_out, outbound_bytesBoth sides aggregate before the join, and the ordering check means the outbound has to follow the archive rather than merely land on the same host. Watch the subsearch row and time limits at scale, and move to tstats if you outgrow them.
Splunk Anomalous engineering file access
index=wineventlog EventCode=4663
Object_Name IN ("*\\engineering\\*", "*\\configs\\*",
"*\\diagrams\\*", "*\\projects\\*")
| search NOT Account_Name IN ("engineer-account-1", "engineer-account-2", "*$")
| stats count AS access_events, dc(Object_Name) AS distinct_files,
values(Process_Name) AS processes,
min(_time) AS first_seen, max(_time) AS last_seen
BY Account_Name, ComputerName
| where distinct_files > 10
| eval window_hours=round((last_seen - first_seen) / 3600, 1)
| sort - distinct_filesMachine accounts are filtered out with the trailing dollar sign. Counting distinct files inside a time window is what separates an engineer opening one project from someone sweeping a directory.
Zeek Cloud storage outbound from OT-adjacent hosts
module AZURITE;
export {
redef enum Notice::Type += { Cloud_Storage_Outbound };
const ot_adjacent: set[subnet] = {
10.20.10.0/24, 10.20.11.0/24,
} &redef;
const cloud_storage: pattern =
/(onedrive|1drv\.ms|sharepoint|drive\.google|dropbox
|mega\.(nz|io)|box\.com|wetransfer|pcloud|mediafire)/ &redef;
}
event ssl_established(c: connection)
{
if ( ! c?$ssl || ! c$ssl?$server_name )
return;
if ( c$id$orig_h !in ot_adjacent )
return;
if ( cloud_storage !in c$ssl$server_name )
return;
NOTICE(Notice::Info($note=Cloud_Storage_Outbound,
$conn=c,
$msg=fmt("OT-adjacent host %s reached cloud storage %s",
c$id$orig_h, c$ssl$server_name),
$identifier=cat(c$id$orig_h, c$ssl$server_name),
$suppress_for=6hr));
}Valkyrie Long-dwell host with engineering data access
Inside Valkyrie, the highest-confidence AZURITE correlation is a host showing sustained access patterns over many weeks combined with engineering data directory access by non-engineering accounts. The platform handles the long-window correlation natively, which is the part that is genuinely painful to maintain by hand in SPL. The hunt equivalent in any toolset is to take an unusual engineering data access event and ask whether the source host carries any other long-dwell anomalies in its history.
If you are working a site without existing sensor coverage, or one where you cannot put a monitoring appliance on the network permanently, this is the sort of assessment our team runs off Cygnet. Same analysis, air-gapped, packed in a case.
Tuning note
AZURITE hunts produce false positives mostly from legitimate engineering activity that looks unusual at first glance. The tuning work is largely about establishing what each engineering account legitimately does and over what time horizon. Once that baseline exists, AZURITE-style activity stands out because it does not match any individual's documented pattern. Budget real time for the baseline. It is the whole hunt.
AZURITE hunts work best on a longer cycle than the rest of the actors covered in this series, because the activity itself unfolds over weeks and months. A single-day hunt will rarely surface a long-dwell actor. A monthly or quarterly hunt with consistent methodology and trending will.