On December 29, 2019, Iran-linked threat actors deployed the Dustman wiper malware against
Bahrain Petroleum Company (BAPCO), the kingdom’s state-owned national oil company.
Dustman, a variant of the ZeroCleare wiper derived from the notorious Shamoon family,
was distributed simultaneously across multiple machines using a compromised antivirus
management console service account. The attackers had initially gained access months
earlier, in Summer 2019, by exploiting a remote code execution vulnerability in a VPN
appliance - likely Palo Alto or Fortinet - establishing persistent access
deep within BAPCO’s network infrastructure.
The attack was partially contained, affecting what BAPCO described as “only a
certain module” of its network. The incident was publicly disclosed on January
9-10, 2020, when Saudi Arabia’s National Cybersecurity Authority (NCA) issued
a public advisory describing the Dustman malware in technical detail. No public
enforcement action was taken by Bahraini authorities under the Personal Data Protection
Law (Law No. 30 of 2018).
## Key Facts
- .**What:** Iran-linked APT34 deployed Dustman wiper via compromised VPN and AV console.
- .**Who:** Bahrain Petroleum Company (BAPCO), the state-owned oil company.
- .**Data Exposed:** Systems destroyed; MBR wiped; six months of prior network access.
- .**Outcome:** Partially contained; disclosed by Saudi NCA; no PDPL enforcement.
## What Was Exposed
Unlike conventional data breaches aimed at exfiltration and monetization, the Dustman
attack was designed for destruction. The primary objective was to render BAPCO’s
systems inoperable by overwriting the master boot record (MBR) and wiping file system
data on targeted machines. The exposure in this case is not a data leak but a systemic
compromise of operational availability and integrity - arguably a more severe
outcome for a critical infrastructure operator.
- .Compromise of VPN appliance infrastructure providing remote access to BAPCO’s
internal network, enabling persistent unauthorized access from Summer 2019 through
the December deployment
- .Hijacking of the antivirus management console service account, granting the
attackers the ability to push executables to managed endpoints across the network
simultaneously - turning a defensive tool into an offensive distribution
mechanism
- .Destruction of master boot records and file system data on targeted machines,
rendering them unbootable and requiring hardware-level recovery or complete
reimaging
- .Potential exposure of network topology, credential stores, and Active Directory
structures during the months-long reconnaissance phase prior to wiper deployment
- .Possible lateral movement into operational technology (OT) segments, given
BAPCO’s role as an oil refinery and production operator with interconnected
IT/OT environments
- .Unknown scope of data exfiltration prior to the wiper deployment - a common
tactic in state-sponsored operations where intelligence collection precedes
destruction
The technical sophistication of Dustman warrants careful examination. Unlike its
predecessor ZeroCleare, which required the attacker to separately stage drivers and
payload components across the target environment, Dustman packaged everything into
a single self-contained executable. This included the legitimate EldoS RawDisk driver
(used to gain raw disk access and bypass Windows file system protections), the
vulnerable VirtualBox driver (used to load the unsigned EldoS driver by exploiting
a known privilege escalation vulnerability in VBoxDrv.sys), and the wiper payload
itself. This monolithic design simplified deployment and reduced the operational
footprint, making detection harder during the distribution phase.
The choice of the antivirus management console as the distribution vector is
particularly noteworthy. Enterprise antivirus solutions typically operate with the
highest system privileges and maintain persistent network connections to a central
management server. By compromising the service account that controls this console,
the attackers effectively co-opted the most trusted software deployment channel in
BAPCO’s environment. This technique mirrors the SolarWinds supply chain attack
methodology - weaponizing trust relationships within IT infrastructure to
achieve maximum reach with minimum detection.
The attribution to APT34 (also tracked as OilRig, Helix Kitten, and Hive0081) places
this attack squarely within Iran’s pattern of destructive operations against Gulf
state energy infrastructure. APT34 is assessed by multiple intelligence agencies to
operate under the direction of Iran’s Ministry of Intelligence and Security (MOIS).
The Dustman attack represented the latest iteration in a lineage that began with
Shamoon’s devastation of Saudi Aramco in 2012 (35,000 workstations destroyed),
continued through Shamoon 2 in 2016-2017, and evolved into ZeroCleare in 2019.
Each iteration demonstrated incremental refinement in evasion techniques while
maintaining the same strategic objective: disrupting Gulf energy production
capabilities.
The timing of the attack - December 29, during the holiday period between
Christmas and New Year - was deliberate. Staffing levels at security operations
centers are typically reduced during holiday periods, incident response teams may be
dispersed, and detection-to-response times are extended. This timing optimization is
a well-documented pattern in destructive attacks, from NotPetya (deployed on the eve
of Ukraine’s Constitution Day) to multiple Shamoon variants (deployed on
religious holidays in Saudi Arabia).
The fact that BAPCO managed to partially contain the attack - limiting
destruction to “a certain module” of the network - suggests that
some degree of network segmentation was in place. However, the attackers’ ability
to maintain access for approximately six months, escalate privileges to compromise
the AV console, and stage a coordinated deployment across multiple machines
simultaneously indicates fundamental gaps in detection and monitoring capabilities
during the dwell time.
## Regulatory Analysis
Bahrain’s Personal Data Protection Law (PDPL), enacted as Law No. 30 of 2018
and effective from August 2019, was technically in force at the time of the Dustman
attack. However, its application to a destructive wiper attack against critical
infrastructure reveals significant gaps in the regulatory framework’s ability
to address state-sponsored cyber operations.
Article 8 of the PDPL establishes the fundamental obligation for data controllers to
implement appropriate technical and organizational measures to protect personal data
against unauthorized access, destruction, or loss. The Dustman attack resulted in the
destruction of data on compromised systems, which may have included personal data of
BAPCO employees, contractors, and potentially customers. The six-month dwell time
between initial compromise (Summer 2019) and wiper deployment (December 2019)
represents a prolonged failure of the security measures required under this article.
The fact that attackers were able to escalate from a VPN appliance compromise to
domain-level access to the antivirus management console suggests inadequate internal
monitoring and access controls.
Article 9 of the PDPL requires that personal data processing be conducted in a manner
that ensures the integrity and confidentiality of the data. The compromise of BAPCO’s
systems over a six-month period raises questions about whether any personal data was
exfiltrated during the reconnaissance phase - a common precursor to destructive
attacks. State-sponsored threat actors routinely collect intelligence before deploying
wipers, and the absence of confirmed exfiltration does not mean it did not occur. Under
Article 9, the burden falls on the data controller to demonstrate that confidentiality
was maintained, not merely to assert that no data theft has been confirmed.
Article 12 addresses breach notification obligations, requiring controllers to inform
the Personal Data Protection Authority when a breach affecting personal data occurs.
The Dustman attack destroyed data on compromised machines, which constitutes a personal
data breach under the PDPL’s definition if any of those machines contained employee
records, HR data, or other personal information. The fact that the incident was disclosed
not by BAPCO or Bahraini authorities but by Saudi Arabia’s NCA raises questions
about whether Bahrain’s breach notification procedures were followed. The NCA’s
advisory focused on the technical indicators of compromise rather than the personal
data implications, suggesting a purely cybersecurity-focused response that may not have
addressed data protection obligations.
Article 13 of the PDPL establishes obligations regarding data security in the context
of data processing environments. For a national oil company that processes personal
data of thousands of employees and potentially interacts with citizen data through
energy distribution services, the security requirements are proportionally higher.
The exploitation of a known VPN vulnerability - for which patches were available
- .as the initial access vector suggests a failure in vulnerability management
that would be difficult to defend under a regulatory inquiry. Patch management for
internet-facing infrastructure is a baseline expectation, not an advanced security
measure.
The maximum penalty under the PDPL is BD 20,000 (approximately $53,000 USD), which
is manifestly inadequate for an incident of this magnitude involving state-sponsored
destruction of critical infrastructure systems. This penalty ceiling highlights a
structural limitation of the Bahraini regulatory framework: it was designed primarily
for commercial data protection violations, not for nation-state attacks against
critical infrastructure. The absence of any public enforcement action following the
BAPCO attack - despite the PDPL being in force - may reflect a practical
recognition that penalizing a state-owned company for being targeted by a foreign
intelligence service would be counterproductive, but it also sets a precedent of
non-enforcement that undermines the law’s deterrent effect.
## What Should Have Been Done
The Dustman attack exploited a chain of failures that, taken individually, each had
well-established countermeasures. The first and most immediate failure was the unpatched
VPN appliance. Both Palo Alto Networks and Fortinet had disclosed critical RCE
vulnerabilities in their VPN products in 2019 (CVE-2019-1579 for Palo Alto GlobalProtect
and CVE-2018-13379 for Fortinet FortiOS), and both had released patches months before
the initial BAPCO compromise. Internet-facing VPN appliances are the highest-priority
patch targets in any enterprise environment because they represent the primary
boundary between trusted and untrusted networks. BAPCO should have maintained a
maximum 72-hour patch window for critical vulnerabilities in internet-facing
infrastructure, with compensating controls (such as IP allowlisting or multi-factor
authentication enforcement) deployed immediately upon vulnerability disclosure while
patches were tested and deployed.
The compromise of the antivirus management console service account represents a
failure in privileged access management. Service accounts that control enterprise
security tools should be subject to the most stringent access controls in the
environment: hardware-backed credential storage, just-in-time access provisioning,
mandatory multi-factor authentication, and continuous monitoring of all authentication
events. The AV management console should have been isolated in a dedicated
administrative segment accessible only from hardened privileged access workstations
(PAWs), not from general-purpose networks that could be reached via lateral movement
from a compromised VPN appliance.
BAPCO should have implemented a tiered Active Directory architecture following
Microsoft’s Enhanced Security Administrative Environment (ESAE) model or its
successor, the enterprise access model. Tier 0 assets - including domain
controllers, the AV management console, and other infrastructure management
systems - should have been isolated in a dedicated administrative forest with
separate credentials, separate workstations, and separate network segments.
This architecture would have prevented the attackers from pivoting from a compromised
VPN appliance to the AV console, because the credentials and network paths required
to access Tier 0 systems would not have been available in the Tier 1 or Tier 2
environments where the initial compromise occurred.
Network detection and response (NDR) capabilities should have identified anomalous
behavior during the six-month dwell time. The reconnaissance activities necessary
to identify the AV console, enumerate its capabilities, and compromise its service
account generate detectable network signatures: unusual LDAP queries, anomalous
SMB traffic patterns, credential harvesting activity (such as DCSync or Kerberoasting),
and lateral movement patterns. A mature security operations center with NDR tools,
properly tuned detection rules, and threat-hunting capabilities should have identified
this activity within weeks, not months. The extended dwell time suggests either
insufficient monitoring coverage or inadequate staffing to investigate alerts that
may have been generated but not triaged.
Application whitelisting on critical systems would have prevented the execution of
the Dustman payload even if it had been distributed via the AV console. While the
AV console has legitimate authority to push executables to endpoints, application
whitelisting policies can be configured to restrict execution to known, signed
binaries. The Dustman executable, despite being packaged as a single file for
operational convenience, would not have matched any legitimate application hash.
Tools like Windows Defender Application Control (WDAC) or third-party application
whitelisting solutions can enforce execution policies even against software pushed
by administrative tools, providing a critical last line of defense against supply
chain and trust-abuse attacks.
Given BAPCO’s role as a national oil company with both IT and OT environments,
the Purdue Model for industrial control system network architecture should have been
rigorously enforced. IT/OT convergence zones should have been protected by
unidirectional security gateways (data diodes) that physically prevent network
traffic from flowing from IT networks into OT environments. The partial containment
that BAPCO achieved may indicate some degree of IT/OT separation, but the full
extent of OT exposure during the six-month compromise period remains unknown and
concerning.
Finally, BAPCO should have maintained and regularly exercised a destruction-specific
incident response playbook. Wiper attacks against Gulf energy infrastructure are not
novel - they have been occurring since 2012. Any organization in this sector
that does not have a detailed, tested response plan specifically for destructive
malware scenarios is operating with willful negligence. This playbook should include
offline backup verification procedures, system rebuild capabilities from golden
images, communication protocols for engaging national CERTs and intelligence agencies,
and pre-established relationships with forensic investigation firms capable of
deploying on short notice.
The Dustman attack on BAPCO was not an isolated incident but the latest chapter in
a decade-long campaign of Iranian destructive operations against Gulf energy
infrastructure. The attack chain - unpatched VPN, privilege escalation to
AV console, simultaneous wiper deployment - exploited fundamental gaps in
patch management, privileged access controls, and network segmentation. Under
Bahrain’s PDPL, the absence of enforcement does not indicate compliance;
it reveals a regulatory framework not yet equipped to address the intersection of
state-sponsored cyber warfare and personal data protection.