AZURITE and the engineering workstation: what Dragos says the group takes, and how to check your exposure

The engineering workstation of a filling hall is rarely on anyone’s list of sensitive systems. It is a tower PC in the automation office, two screens, an asset label peeling off the side. On it sit the PLC projects of every machine on the line, the HMI runtime files, the alarm list someone exported last spring for the periodic alarm review, and a folder of network drawings nobody has tidied since the last shutdown. It is also the only computer on site allowed to download a program into any controller. Two floors up, the VPN gateway the integrator uses is still waiting for a firmware update pencilled in for the next maintenance window.

According to Dragos, that workstation is exactly what one threat group comes for. Dragos calls the group AZURITE. It does not encrypt the ERP and it does not ask for a ransom. In Dragos’s account it studies how the process works, what makes it alarm and how the controllers are programmed, and it leaves with that knowledge.

Below: what Dragos says, which parts government sources confirm and which they do not, why the engineering workstation weighs so much on a GMP site, and how to check your own exposure without waiting for a name to turn up in your logs.

What Dragos says AZURITE does

AZURITE is Dragos’s name for a cluster of activity it has tracked since 2021. It was one of three new groups announced with Dragos’s OT Year in Review in February 2026, and its public profile went up on 15 June 2026. Everything in this section is Dragos’s description, and only a summary: the technical detail is kept for customers of its intelligence service, so the public picture is incomplete by design.

Dragos lists the targets as manufacturing, automotive, electric, oil and gas, pharmaceutical, the defence industrial base and government, in the United States, Taiwan, Europe, Japan, South Korea and Australia. Pharmaceutical manufacturing is named explicitly.

The way in is the internet-facing edge: VPNs, firewalls and remote access gateways, with Ivanti, Fortinet, Cisco and F5 equipment among the assets Dragos says were exploited. The traffic is routed through compromised small office and home office (SOHO) routers and network-attached storage (NAS) boxes organised into relay networks, with rented virtual private servers for command and control and for exfiltration.

Once inside, the group uses what Windows already provides rather than its own malware (living off the land), plus web shells on the servers it compromises, SOCKS tunnels and Remote Desktop Protocol (RDP) sessions to the engineering workstations. Dragos insists the reconnaissance is slow, to stay below internal detection.

What it takes: alarm data, PLC configurations, HMI data and process information.

That last line is the one a plant should read twice. Nobody resells an alarm list. Knowing what triggers alarms and how the control loops are built is what an attacker needs to prepare something aimed at one particular kind of process. Dragos therefore advises treating any AZURITE presence in an OT environment as prepositioning for later destructive operations rather than an opportunistic intrusion. It also assesses that AZURITE shares tasking and targeting objectives with VOLTZITE, another group it tracks, and states that it does not do political attribution.

What public sources confirm, and what they do not

Dragos lists overlaps between AZURITE and names used by other trackers: Flax Typhoon, Ethereal Panda, UNC5923, Raptor Train and Red Dev 54. Some of those names appear in government documents, so part of the profile can be checked. The table does it line by line.

Two cautions. The 2024 advisory itself warns that security companies group actors their own way and that those groupings “may not be a 1:1 correlation” with the US Government’s understanding. And MITRE ATT&CK, the public catalogue most defenders work from, had no group entry for AZURITE or for Flax Typhoon when this was written.

So the part that matters most to a plant, the visits to engineering workstations, rests on Dragos alone. That is no reason to wave it away; Dragos sees OT networks that government agencies never see. It is a reason to act on the behaviour, which is well documented and cheap to check, and not on the name.

Why the engineering workstation

On most sites the automation knowledge of the plant ends up concentrated on this one machine. On a GMP site that means:

• the PLC projects, with the logic, the interlocks and the phase parameters: the hold time of a sterilisation, the limits of a fill-weight check, the sequence of a clean-in-place cycle;
• the alarm configuration (setpoints, priorities, delays), in other words which deviation raises what, and how long before an operator would notice;
• the HMI projects: screens, user levels, what the operator is shown and what is hidden;
• the address plans, drawings and the list of controllers with their firmware;
• and the path itself: engineering software with the rights to upload a program from any controller and to download one into it.

MITRE’s ATT&CK for ICS has names for this. Theft of Operational Information (T0882) is stealing operational information “as a direct mission outcome for personal gain or to inform future operations”. Program Upload (T0845) and Data from Information Repositories (T0811) are two ways of collecting it. None of the three changes anything in the process, which is why they go unnoticed.

For a quality unit, a stolen alarm list is a confidentiality event, not a batch deviation. It still becomes a GMP matter, for two reasons. Access that can read a PLC project can usually write one, and if you cannot show that nobody changed the program, the validated state of the equipment is open to question. EU GMP Annex 11 sets the expectation in §12.1: “Physical and/or logical controls should be in place to restrict access to computerised system to authorised persons.” Then §13: “All incidents, not only system failures and data errors, should be reported and assessed.” An intrusion that reached the engineering workstation belongs in that process, with quality in the room, and not only in a security ticket.

What it means for your defences

Nothing exotic. Dragos’s profile points at ordinary controls, in the places where they are usually weakest.

1. The edge device is the front door. VPNs, firewalls and remote access gateways belong to IT on most sites and get patched on IT’s calendar. In February 2025 the Australian, Canadian, British and US cyber agencies and other partners published joint guidance on edge devices for precisely that reason. The OT team’s question is short: which edge devices open a path to OT, and who patches them within days when one of their flaws lands in CISA’s Known Exploited Vulnerabilities catalogue?
2. No direct remote desktop into the engineering workstation. An RDP session from the office network straight onto the workstation is the step Dragos describes. Remote sessions should end on a jump host in the DMZ, with multi-factor authentication and recording, as described in vendor remote access without opening your cell network. CISA’s May 2025 list of primary mitigations for OT says the same in plain words: secure remote access, segment IT from OT.
3. Treat project files as controlled data. Most sites know where the master copy of a PLC program lives. Far fewer know how many other copies exist: on a file share, on the integrator’s laptop, attached to an email from the last change. Each copy is one more place to steal it from.
4. Look for slow, quiet activity. When the attacker lives off the land, his commands are the administrator’s commands. The joint guide on living-off-the-land techniques published by CISA and its partners in February 2024 is blunt about it: detection depends on logging and on a baseline of normal behaviour. On an engineering workstation, normal is a short list: a few named engineers, at known hours, from known machines.
5. Know what the controllers are running. Comparing the program in each critical PLC with the approved master is a validation habit and a security control at once, and the only check that answers the question an intrusion raises: was anything changed? A master you have never restored is an assumption, see a backup is a hypothesis, a restore is evidence.

Eight checks for your own exposure

None of them needs a new tool or a shutdown, and each produces a short record you can file.

1. List every internet-facing device on the site: firewalls, VPN concentrators, remote access gateways, file transfer servers. For each, note the vendor, the version, the owner, and whether any of its flaws is in the Known Exploited Vulnerabilities catalogue.
2. Read the administrative logins on those devices over the last quarter. Source addresses nobody can explain, or hours nobody works, are the finding.
3. Draw every path to each engineering workstation: which networks can open RDP, file shares or remote tools to it, according to the firewall rules as they are and not as the drawing says.
4. Pull the remote logon history of each engineering workstation and set it against the list of people who should connect. A service account logging on interactively deserves a question.
5. Check the servers you expose for web shells with the vendor’s integrity-check tools where they exist, and look for script files nobody remembers deploying.
6. Count the copies of your PLC and HMI projects and write down where each one lives. Delete what has no reason to exist; protect the rest.
7. Compare the online program of your critical controllers with the approved master and record the result as you would any periodic review.
8. Find the small routers and NAS boxes on site, including those built into machines and those in offices nobody manages. The 2024 advisory asks owners to disable unused services, apply updates, replace default passwords, reboot regularly and retire equipment past its end of life. A box on your network that serves as someone else’s relay is also a way in.

Where to start

Start this week with checks 1 and 7. The list of internet-facing devices and their patch levels tells you how easy the front door is; the comparison of PLC programs with their masters tells you whether anything behind it has already been touched. Each fits in a day, both need IT and automation at the same table, and both give quality a record it can read. Then close the direct remote desktop paths into the engineering workstations. Of all the changes, that one breaks the path Dragos describes most directly.

Five common mistakes

• Waiting for the name. No log will ever say AZURITE. What you can see is the behaviour: an unusual remote session to an engineering workstation.
• Leaving the edge devices to IT’s calendar. A VPN in front of OT is an OT risk, whoever administers it.
• Calling theft harmless because production never stopped. Dragos’s point is that what is taken today prepares a later attack. No process upset does not mean no intruder.
• Keeping the incident out of the quality system. An intrusion into the engineering workstation puts the validated state of the controllers in question, and Annex 11 expects it to be assessed.
• Forgetting the copies. The master program sits in a protected repository. The copy on the integrator’s laptop and the export on the shared drive do not.

Your PLC projects and alarm lists describe your plant better than any drawing. Protect them as if someone were already reading them.

References

• Dragos, *AZURITE threat group profile*, 15 June 2026 (the item behind this article and the source of every statement about AZURITE).
• FBI, CNMF and NSA with allied partners, *People’s Republic of China-Linked Actors Compromise Routers and IoT Devices for Botnet Operations*, joint advisory, 18 September 2024.
• MITRE ATT&CK, *Volt Typhoon, G1017* and ATT&CK for ICS *T0882 Theft of Operational Information*.
• CISA, FBI, EPA and DOE, *Primary Mitigations to Reduce Cyber Threats to Operational Technology*, 6 May 2025.
• CISA and partners, *Identifying and Mitigating Living Off the Land Techniques*, 7 February 2024.
• European Commission, *EudraLex Volume 4, Annex 11: Computerised Systems*, §12 and §13.