Blog

Maritime Cyber Threat Briefing #13

Briefing #12 examined what happens when the network perimeter fails. When an edge device that was supposed to keep an adversary out becomes the entry point instead. This briefing examines the layer behind it: the endpoint security that is supposed to notice an adversary once they are already inside. A ransomware operation documented by Symantec and Carbon Black in July 2026 defeats that layer using a mechanism that should not exist. It does not exploit a flaw in endpoint software. It carries a genuine Microsoft signature, obtained through the process Microsoft itself designed to establish trust in kernel-mode code, and uses that trust to make the security software blind rather than absent. The agent keeps running. It simply stops seeing.

No maritime or transportation-sector victim of this campaign has been publicly confirmed. This briefing is an exposure analysis, not incident reporting, and it should be read as such throughout. The reason it belongs in this series regardless is structural: the control this technique defeats is not optional in modern vessel cyber-resilience design. It is one IACS explicitly requires shipowners to install.

The ransomware, precisely

The threat actor tracked by Symantec as Hyadina has run one continuous ransomware-as-a-service operation since March 2022, rebranding twice while keeping the same core tooling and operational habits. Monster appeared first, a Delphi-based locker targeting 32-bit Windows systems. In June 2024 the operation rebranded as Beast, adding Linux and VMware ESXi support and multilingual capability. In May 2026, Symantec identified the third iteration: GodDamn.

In the intrusion Symantec and Carbon Black investigated, the attackers gained initial access by a vector that could not be determined [account compromise is the common assumption for this actor’s profile] then established persistence with AnyDesk, installed in a user’s Music folder on the first host as a manual, hands-on-keyboard action rather than an automated deployment. Credential harvesting followed, using Mimikatz alongside a NirSoft-based toolkit, with PsExec for lateral movement. On a second host, the attackers staged a binary named symantec.exe, disguised as the defender’s own product [a small but telling detail], since it is designed to look normal to an administrator glancing at a process list rather than to defeat automated detection. That binary dropped the kernel driver at the centre of this briefing.

Five days elapsed between initial access and ransomware detonation, across at least ten hosts, before encryption began.

PoisonX and the mechanism that matters

The driver, filename g11.sys, carries a signature attributed to Microsoft Windows Hardware Compatibility Publisher. Once loaded, it operates at kernel privilege to terminate security-product processes and strip the user-mode API hooks that antivirus and EDR agents rely on to observe system activity. Symantec’s assessment is direct: the driver has no legitimate use case, and its adoption by Hyadina represents a deliberate escalation in defensive-evasion capability.

This is commonly described in press coverage as a Bring-Your-Own-Vulnerable-Driver, or BYOVD, attack, and the label is close enough to be useful but not precise enough to guide defense. Classic BYOVD abuses a flaw in an existing legitimate driver. A vulnerability the attacker did not create but discovered. PoisonX appears to have been built from the outset for this purpose and still obtained a valid signature, which is a different and in some ways more serious problem, because there is no underlying software flaw to eventually patch.

How that signature was obtained is worth understanding precisely, because the explanation is not “Microsoft was fooled”. To submit a driver for attestation signing under the Windows Hardware Compatibility Program, a developer needs a Hardware Dev Center account backed by an Extended Validation code-signing certificate. A credential that requires real-world identity and organizational verification to obtain. Attestation signing, the relevant path for this kind of submission, does not require the formal hardware lab certification testing that full WHCP certification does. Microsoft’s own documentation states plainly that attestation-signed drivers are trusted by Windows, but their functionality is not guaranteed. The programme verifies who is submitting the code. It does not verify what the code does. Attestation signing establishes publisher identity and package integrity, but it is not equivalent to full behavioural or compatibility certification. Microsoft’s own documentation states that attestation-signed drivers do not undergo Hardware Lab Kit testing, are not Windows Certified, and carry no assurance regarding compatibility or functionality. That distinction is central to the PoisonX case: a valid signature can tell Windows who submitted a package and whether it was altered after signing, but it does not, by itself, prove that the driver’s operational intent is benign. Signing Options

The failure is therefore not that digital signing provides no value. It is that identity assurance and “software behavior” assurance are different controls. And the industry too often treats the first as though it guarantees the second.

The Chain of Inherited Trust

The deeper issue is not a single signing decision. It is the chain of trust that follows it.

Windows accepts the driver because its package carries a valid Microsoft signature. Endpoint software operates on the assumption that permitted kernel code belongs inside the trusted computing base. Asset-management systems then record that the security agent remains installed and running. Audit and compliance processes may accept that recorded state as evidence that malware protection is operational.

Each layer inherits confidence from the one before it. PoisonX exploits that inheritance. It does not need every layer to fail independently. It needs the first trust decision to propagate through the rest of the environment.

The signature validates package provenance and integrity. The operating system converts that into permission. Monitoring converts permission into apparent normality. Compliance converts apparent normality into assurance.

This is why the incident matters beyond Windows driver signing. It demonstrates how a narrow technical trust decision can become an inaccurate board-level statement about operational resilience.

PoisonX Is a Capability, Not a Campaign

PoisonX did not appear for the first time inside the GodDamn intrusion. The driver had already been documented earlier in 2026 in a separate campaign targeting organizations in Japan and China, where it was deployed alongside the modular 10FXRAT remote-access tool. Symantec later observed it in a financially motivated GodDamn ransomware operation. The available reporting does not establish that the two campaigns were conducted by the same actor, and they should not be conflated. What it does establish is more strategically important: the same kernel-level defensive-evasion capability has moved across distinct operational contexts. GodDamn Ransomware

That makes PoisonX better understood as an access-enablement component than as a feature belonging exclusively to one ransomware family. Once a signed driver capable of degrading endpoint visibility enters circulation, it can be reused, transferred, sold, or incorporated into different intrusion chains. The defender is therefore not dealing only with Hyadina. The defender is dealing with the availability of a reusable capability whose value applies equally to espionage, credential theft, ransomware, and long-term persistence.

For maritime organisations, this distinction matters. Threat assessments built around named ransomware groups can become obsolete when techniques and components migrate faster than actor labels. The relevant question is not only whether GodDamn targets shipping. It is whether any actor targeting shipping can obtain or reuse the same driver.

A Recurring Failure in the Trust Model

This is not a novel failure. In December 2022, following joint reporting from Mandiant (part of Google Cloud), SentinelOne and Sophos, Microsoft revoked certificates associated with maliciously signed drivers in the Poortry and Stonestop case. Those drivers followed a closely related pattern: trusted kernel code built or repurposed to disable security software and support ransomware operations. GodDamn and PoisonX therefore represent the recurrence of a structural weakness in the trust model, not the appearance of an entirely new one.

Four years after a mass certificate revocation addressed the previous wave, the same trust-model problem has returned in a new operational form. The lesson is that revocation removes known keys: it does not redesign the system that issued trust.

Why the two standard defenses are weaker in practice than the coverage implies

Microsoft’s own guidance for this threat class centre on two controls, and both deserve a more precise treatment than “keep them updated”.

1. The Microsoft Vulnerable Driver Blocklist is an important control, but it is not a complete answer to newly weaponized signed drivers. Microsoft currently updates the blocklist quarterly and also distributes blocklist changes through monthly Windows servicing. Organisations can additionally deploy the latest recommended rules through App Control for Business. Even so, newly identified drivers may remain usable before they are evaluated, added, distributed, and enforced across every affected system. Microsoft also acknowledges that some blocks may be delayed where immediate enforcement could break legitimate devices or software. The practical gap is therefore no longer best described as an annual update problem. It is the interval between discovery, policy inclusion, fleet-wide distribution, enforcement, and operational validation. Microsoft Learn
2. Hypervisor-Protected Code Integrity (HVCI, also called Memory Integrity) availability and suitability depend on a combination of processor, firmware, virtualization, Secure Boot, IOMMU, and driver-compatibility conditions. Microsoft’s current automatic-enablement baseline generally centre on Intel eighth-generation or later processors and “AMD Zen 2” or later, together with supporting UEFI and platform-security features. Older systems may fail to meet that baseline, may lack required capabilities, or may incur unacceptable compatibility and performance consequences. In maritime environments, the decisive question is therefore not simply whether HVCI exists in Windows, but whether the specific OEM-controlled hardware and software configuration can support and enforce it without affecting an approved operational system. Memory Integrity

Maritime exposure: what is documented and what is not

To be precise about the limits of what can be asserted here: Hyadina’s confirmed victim profile across all three ransomware generations spans

• manufacturing
• construction
• healthcare
• business services
• education.

No maritime, port, or logistics victim has been publicly reported. The group’s targeting pattern: opportunistic, financially motivated, avoiding machines geolocated in the Commonwealth of Independent States. This shows no evidence of deliberate maritime interest. This briefing is not reporting a maritime attack. It is describing why the maritime sector is structurally exposed to this class of technique regardless of who deploys it next.

That exposure rests on three points, each independently documented.

1. The fleet’s underlying Windows estate skews toward exactly the hardware generation this control gap concerns. Marlink‘s own fleet telemetry, published around the October 2025 end-of-support date for Windows 10, found that just over forty percent of surveyed maritime systems were still running Windows 10, against roughly half on Windows 11. A meaningful share of that population sits on hardware or vendor-locked images that predate HVCI’s hardware baseline.
2. The upgrade path on much of this equipment does not run through the ship’s IT department. Bridewell‘s analysis of the maritime Windows 10 exposure makes a specific and important point: an ECDIS terminal or other OEM-locked navigation console built on a fixed vendor image frequently has no viable upgrade path without manufacturer recertification. A shore-based IT team cannot simply enable Memory Integrity on a bridge system the way it could on an office laptop, even where the underlying hardware would technically support it. Because doing so may invalidate the vendor’s type approval or void support arrangements. Remediation runs through the equipment manufacturer’s release cycle, not the ship’s patch cycle. And that cycle, for many maritime OEMs, is measured in years rather than months.
3. The specific control PoisonX defeats is not discretionary under current classification requirements. IACS UR E26 states plainly that malware protection shall be implemented on computer-based systems within its scope. That where an industry-standard anti-virus or anti-malware product is available for the operating system in question, it shall be installed, maintained and kept regularly updated, subject to a narrow exception where installation would impair the system’s function. PoisonX does not need to defeat a theoretical or aspirational control. It defeats the exact control class E26 obligates vessels contracted after 1 July 2024 to run. It does so in a way that leaves the required software installed, apparently functioning, and silently blind. A vessel may appear compliant through conventional evidence [the product is installed, licensed, updated, and reporting a healthy status] while a PoisonX-class driver has degraded the underlying visibility on which that status depends.

Detection: what to look for, without a working exploit as a guide

Consistent with this series’ standard on attack methodology, the guidance below stays at the level of observable indicators and architectural response, not driver-loading technique.

• Unexplained new kernel drivers, regardless of signature status. A signed driver is not a trusted driver by default. It is a driver whose submitter was identity-verified. Any newly appearing “*.sys” file that was not part of a known, change-controlled installation [vendor updates, planned maintenance software, approved monitoring agents] warrants investigation on that basis alone. Independent of whether it carries a valid Microsoft signature.
• Security software that goes quiet rather than absent. The specific danger of this technique is that the endpoint agent’s process continues to run and continues to appear “installed” in inventory tools, while its actual visibility into system activity has been severed. A monitoring regime built only around “is the agent running” will not catch this. Regimes that also verify the agent is actively generating telemetry, heartbeat and event-volume monitoring, not just process-presence checks: Will.
• Impersonation of security-product filenames or installers. The “symantec.exe” staging file in the documented intrusion was named specifically to look unremarkable to an administrator scanning a process list. File-name matching alone is a weak control, but combined with hash and publisher verification against known-good vendor releases, it closes an easy gap.
• Cross-reference published indicators regardless of whether the local EDR has flagged anything. Symantec has published the SHA-256 hashes for PoisonX and the associated staging binary in its Protection Bulletin. The entire premise of this technique is that a blinded EDR will not flag what happens after it is blinded. So the indicator sweeps that do not depend on the local agent having caught the initial compromise are the only reliable way to confirm a system is clean.

Look for disagreement between systems

A blinded endpoint often reveals itself through disagreement rather than absence. Identity systems may record privileged logons that the endpoint does not explain. Network sensors may observe east-west connections or remote administration traffic while the host produces no corresponding process telemetry. A central log platform may show a sudden fall in event volume from one machine even though the device remains online and the agent continues to report a healthy status.

The detection model should therefore compare independent sources:

• endpoint event volume and heartbeat;
• identity and privileged-logon activity;
• network and DNS telemetry;
• firewall, VPN, and remote-access records;
• service and driver installation events forwarded off-host.

When the network says activity occurred and the endpoint says nothing happened, the silence is itself an indicator.

Mitigation, calibrated to what a maritime IT/OT estate can actually do

• Where HVCI is achievable, enable it, and treat the exercise as a compatibility project rather than a toggle. For shore-side infrastructure and any bridge or engine-room Windows system on hardware from the qualifying generation onward, Memory Integrity meaningfully raises the cost of this technique. Budget for driver-compatibility testing before enabling it in production, since incompatible third-party drivers will be blocked and can affect specialised maritime software.
• Where HVCI is not achievable [which will be a substantial share of the fleet for some years yet] compensate architecturally. This is precisely the case IACS UR E26 network segmentation exists to address: isolate the systems that cannot receive this class of protection, restrict what can reach them, and ensure that a compromise on an unprotected navigation or cargo system cannot pivot laterally into segments that can be protected. A vessel’s cyber-resilience posture should assume that some endpoints will remain permanently unable to run the strongest available kernel protections, and design the network around that reality rather than around an assumption that every system will eventually be upgraded.
• Treat “the antivirus is installed and shows green” as a necessary but insufficient compliance signal. E26 compliance audits and internal cyber risk assessments should distinguish between confirming a product is installed and confirming it is “actively generating telemetry”. The gap between those two states is exactly where this technique lives.
• Restrict driver installation privileges as a baseline control, independent of signature status. Loading a new kernel driver should require the same change-control discipline as any other privileged system modification, on shore infrastructure and on vessel IT systems alike.
• Maintain offline, verified indicator feeds for vessels with limited connectivity. Given that vessels cannot always pull real-time threat intelligence, shore-based cyber teams should periodically push verified indicator sets [including published hashes for campaigns like this one] to fleet systems during scheduled connectivity windows. Rather than relying solely on the vulnerable driver blocklist’s own update cadence, which is already slow even for well-connected shore networks.

Five questions management should ask

1. Can we identify every kernel driver authorised on critical maritime systems?
2. Can we detect when endpoint telemetry degrades while the agent remains online?
3. Which vessel systems cannot support HVCI or equivalent protection and why?
4. Who is responsible for remediating an OEM driver-control limitation?
5. Can we independently demonstrate that malware protection is effective, not merely installed?

Regulatory considerations

• Mandatory. IACS UR E26 and E27, applicable to vessels contracted for construction on or after 1 July 2024, are the direct regulatory anchor for this briefing. E26’s explicit requirement for installed and maintained malware protection is the control this technique targets, and E26’s network segmentation requirements are the primary compensating control where endpoint protection cannot be fully realized. The International Maritime Organization Guidelines on Maritime Cyber Risk Management, referenced against MSC.428(98) and discussed at length in my Maritime Cyber Insights Article #4, establish the risk-management framework within which this exposure should be assessed and documented. Though they do not specify technical controls at this level of detail. Where NIS2 applies through the relevant national implementing legislation, its requirements for cybersecurity risk management, incident detection, response, governance, and reporting are directly relevant to the distinction between a security product being installed and the underlying security capability remaining operational. Applicability and implementation must still be assessed jurisdiction by jurisdiction. As of July 2026, most EU Member States had notified transposition measures, but Ireland, Spain, France, and the Netherlands had not notified full transposition and were referred by the European Commission to the Court of Justice of the European Union.
• Not yet mandatory, but directly relevant. Neither the IMO framework nor IACS E26/E27 currently mandates a specific standard for kernel-level driver control (HVCI or equivalent) or for hardware baselines capable of supporting it. This is a genuine gap between what current regulation requires [malware protection software be present] and what a sophisticated adversary has demonstrated defeats that requirement without violating it.

PoisonX also exposes a responsibility gap between the shipowner, the system integrator, the OEM [Original Equipment Manufacturer], and the classification process. A shipowner may be required to maintain malware protection while lacking authority to modify the underlying driver policy, operating-system image, or security configuration of an OEM-controlled system. The owner carries the operational risk, while the technical ability to harden the platform may sit with the manufacturer.

Future assurance should therefore ask OEMs to provide more than a statement that antivirus is supported. For each Windows-based system, owners and class should seek:

• the supported kernel-security configuration
• HVCI and driver-control compatibility status
• an approved-driver inventory
• the process and maximum timeline for revoking a compromised driver
• a defined telemetry-health test
• compensating controls where platform limitations prevent modern enforcement

This turns malware protection from a product checkbox into an evidenced system capability.

The uncomfortable conclusion of this briefing is not that GodDamn will target a vessel next. It may never do so, its operators show no sign of interest in the sector. The conclusion is that the trust mechanism PoisonX exploits is a general-purpose weakness available to any actor able to obtain or reuse a maliciously signed driver, and that maritime cyber assurance places significant reliance on the exact control class this technique can silently degrade.

The real lesson of PoisonX is not that signatures have become meaningless. They have not. Signatures establish provenance and integrity, and both remain essential. The lesson is that provenance is not purpose, integrity is not safety, and installation is not effectiveness.

Maritime cyber compliance increasingly requires controls that sophisticated actors know how to leave visibly present and operationally useless. The next maturity step is therefore not another checkbox. It is the ability to prove [continuously and independently] that the required control is still performing the function for which it was installed.

A verified identity is not a verified intent. A running agent is not a seeing agent. A compliant system is not necessarily a resilient one.

---

Maritime Cyber Threat Briefing is an independent series covering cyber threats, vulnerabilities, and risk management across the global maritime industry. It is published by Alexandros Engelen, a Cybersecurity Strategist, specializing in maritime cyber risk.

Sourcing note. This briefing draws on primary and authoritative sources including the Symantec and Carbon Black (Broadcom) Threat Hunter Team’s published analysis and Protection Bulletin covering the GodDamn/PoisonX intrusion; Microsoft Learn documentation on driver code-signing requirements, attestation signing, the Windows Hardware Compatibility Program, and Hypervisor-Protected Code Integrity hardware requirements; Microsoft’s own support documentation on the Vulnerable Driver Blocklist update cadence; contemporaneous reporting on the December 2022 Poortry/Stonestop certificate revocations; Marlink’s published fleet telemetry on maritime Windows 10 prevalence; Bridewell’s analysis of maritime OEM-locked system upgrade constraints; and the primary text of IACS Unified Requirement E26. Attribution of GodDamn to the Hyadina threat actor and its lineage through Monster and Beast follows Symantec’s published assessment. No maritime, port, or logistics-sector victim of this campaign has been publicly confirmed at the time of writing; all maritime-specific content in this briefing is exposure analysis based on documented fleet characteristics and regulatory requirements, not incident reporting. Discussion of the driver’s mechanism is deliberately confined to the level required for detection and defence; no driver-loading technique, exploitation detail, or code-signing circumvention method beyond what Microsoft itself has published is included. No commercial relationship exists between the author and any vendor, product or service referenced.