APT28's NATO Shipbuilder Hack: What's Known

On 20 October, Symantec's Threat Hunter Team published the inside story of a Russian intelligence operation that had been sitting in a NATO naval shipbuilder's network for about two months. Unlike most breach stories, almost none of this rests on an attacker's word. It is a vendor walking through an intrusion command by command, from the Word document that opened the door in July to the launcher still turning up on the network in late September.

The group is APT28, also called Fancy Bear, Forest Blizzard, BlueDelta, and in Symantec's own naming, Swallowtail. According to the US government it is a unit of Russia's military intelligence service, the GRU, and it is the same group tied to the 2016 hack of the Democratic National Committee. This time it went after three organisations in two unnamed NATO member states: a law enforcement agency, a maker of military aircraft engines, and the naval shipbuilder where investigators found the most activity.

What makes the report worth reading is not the target, which most of us have nothing in common with. It is the method. There was no exotic malware and no zero-day. The attackers used a Word macro, a one-pixel browser window, Windows' own built-in SSH client, and a short PowerShell script, and that was enough to steal credentials and tunnel into a defence manufacturer's internal network. The same techniques land on ordinary companies every week. Below: what the evidence actually shows, the one big thing it can't, and what any organisation should take from it.

How the intrusion unfolded#

It started with an email. On the afternoon of 24 July 2026, someone at the shipbuilder opened a Word document straight from an Outlook attachment, which is how Symantec knows it arrived as a phishing email rather than a download. The document carried a heavily obfuscated macro that, once enabled, quietly dropped a handful of files and started HOOKEDGE, the lightweight backdoor APT28 has been refining all year. HOOKEDGE was first documented in August by Recorded Future, which watched the group use it against government and diplomatic targets in Romania, Spain and Türkiye.

HOOKEDGE is deliberately unglamorous. Instead of a custom downloader that security tools might flag, it drives a hidden, off-screen Microsoft Edge window, sized to a single pixel and parked far off the edge of the screen, and uses it as its web client. The backdoor fetches an instruction, runs it, sends the output back, and repeats on a timer. For the first task the operators ran a long reconnaissance script: who is logged in, what the network looks like, and a set of test connections to Dropbox, Google, Microsoft's login page and Mega, plus a bare IP address. They were checking which way out of the network was open before committing to anything.

Then it went quiet for about three days. On 27 July the operators came back, and this is where the publicly documented version of HOOKEDGE stops and new behaviour begins. A fresh variant stopped using the webhook.site service that every earlier sample relied on, and instead talked directly to a server the attackers controlled at 185.82.218[.]119. Over the next half minute they ran seven commands in quick succession, each landing two to eight seconds after the last. That cadence is the tell: a person at a keyboard, not an automated beacon.

From there they stole credentials two different ways, opened a tunnel out of the network, and mapped the internal estate over the following days, including a DNS lookup for what looked from its name like a mail server. By 31 July they pushed down a tool whose job remains the report's biggest open question. After that the hands-on activity stopped, but the infrastructure did not disappear. The same files were still on the host roughly four weeks later, and the launcher was seen once more on 24 September, the most recent sign of life. That is what "a two-month intrusion" means here: not two months of constant activity, but a foothold that stayed live long after the operators finished their busy week.

What's confirmed and what isn't#

The useful thing about this report is how little of it is guesswork. Symantec reconstructed the attack from the commands the operators actually ran on the host. That makes the confirmed column unusually strong, and throws the one real unknown into sharp relief.

Two things are worth drawing out.

This is a vendor's reconstruction, not a claim to deflate. A lot of breach coverage, including the ShinyHunters FBI story we covered last month, starts with an attacker boasting and then slowly shrinks as facts arrive. This is the opposite. The hard part here is not whether it happened, but what the attackers were ultimately after, and that is the part the evidence can't reach.

"Access" is not the same as "data stolen." Symantec documents the attackers getting in, stealing credentials, and building a route into the internal network. It does not claim to show warship designs walking out the door. That restraint is the honest position, and it is worth copying when you read the more breathless write-ups.

The door: a Word macro, years after they were supposed to be dead#

The uncomfortable detail is the entry point. Microsoft has blocked macros in files from the internet by default since 2022. When you open a macro-enabled document that came from an email or a download, Office is supposed to show a red "Security Risk" banner with no one-click way to enable it. So how did a macro still work against a defence manufacturer in late 2026?

The honest answer is that the default raised the bar without removing the technique. The block only applies on Windows, only to recent Office versions, and only when the file carries Windows' "Mark of the Web" tag. It does nothing if an organisation runs older or perpetual Office, if an administrator has not enforced the policy, if the file reaches the user by a route that strips the tag, or if the user is talked through the handful of steps needed to unblock it. APT28's lure displayed a fake error message precisely to nudge the recipient into enabling content. A determined phishing operation only needs one of those gaps, and large organisations usually have at least one.

The lesson is not "macros are solved." It is that the macro block is a setting you have to actually enforce and verify, not a thing that happens on its own. This is the recurring theme in what actually breaks company security: the breach almost never starts with something clever. It starts with an ordinary feature nobody got around to turning off, and a person who was busy.

Stealing credentials without dropping a tool#

Once inside, the operators needed credentials, and they took them two ways, neither of which involved a recognisable hacking tool that antivirus would flag.

The first was blunt. They pushed an SSH private key onto the machine, renamed it id_rsa, tucked it in a folder dressed up to look like an Adobe directory, and set its permissions. Then they used that key to open a connection out to their own server (more on the tunnel below).

The second is the clever one, and worth understanding because it is a common technique against ordinary Windows networks. They ran a short PowerShell script that stood up a fake web server listening on the machine's own loopback address, then forced the same machine to authenticate to that fake server. Windows helpfully handed over an NTLM authentication handshake, which the script captured. From one captured handshake an attacker can try to crack the account's password offline, or relay it to log in to another system on the network as that user. It is the same idea as well-known attacker tools like Responder, rebuilt as a throwaway script so there is no tell-tale binary on disk.

This works because NTLM, a decades-old Windows authentication protocol, is still switched on by default. Microsoft has deprecated it and is moving toward disabling network NTLM by default, but that change lands in a future Windows release, so for now the coercion trick still works almost everywhere. The joint US and allied advisory on this same GRU unit is blunt about the fix: on-premises networks should block and alert on NTLM and SMB requests to external infrastructure, and plan to disable NTLM entirely in favour of Kerberos and certificate-based authentication.

The tunnel out: Windows' own SSH client, pointed the wrong way#

With that planted key, the operators opened an outbound SSH connection to their own server and asked it to forward a port back through the tunnel. In plain terms, they turned the compromised machine into a doorway: a persistent, backgrounded link that let them reach from their own infrastructure into the shipbuilder's internal network through that one host, rather than a single remote-access session they would have to re-establish.

The quiet point here is the tool they used. It was ssh.exe, the SSH client that ships with Windows itself. Microsoft confirms OpenSSH is an optional component that is not installed by default on Windows 10, 11, or most Windows Server versions, and installed but not enabled on Server 2025. So it is not on every machine, but where it has been turned on, which is increasingly common, it gives attackers a signed, trusted, built-in way to tunnel out that no malware scanner will question. This is "living off the land": using the defender's own software so there is nothing foreign to detect.

A tunnel like this only works if the traffic can leave. A few hours after it went up, the operators tested it with DNS lookups of internal hostnames, then eventually killed it, perhaps just to rotate sessions. The defence that would have mattered most is controlling what leaves the network, not only what comes in.

The loader nobody can read#

On 31 July the operators pushed down two more files. One they named ld.exe, the other Events.dat. They ran the first with a decryption key and the path to the second as arguments.

Symantec analysed ld.exe and found it to be a reflective loader: a small program that takes an encrypted file and a key, decrypts the file in memory, and runs whatever code comes out, without ever writing that code to disk where it could be scanned. The decrypted content starts with a four-byte marker, and the loader calls a function named ExecuteLoader. That is as far as the analysis goes, because the encrypted file it was built to run, Events.dat, was never recovered.

So the single most important question about this intrusion, what the attackers ultimately installed and ran on a NATO defence manufacturer, has no answer. Symantec is clear about this: the command line reveals the key and the filename, but not the payload itself, so its ultimate function is unknown. A credible threat-intelligence team said plainly that it does not know, which is both the honest position and a reminder of how much of an espionage operation stays invisible even after it is caught.

Why this matters even if you'll never build a warship#

Almost no reader of this blog builds submarines. The reason to pay attention is that the target was elite but the playbook was completely ordinary.

Walk back through it. A phishing email with a macro. A browser used as a downloader. A built-in SSH client used as a tunnel. A PowerShell script to coerce a credential. Not one step required a secret flaw or a tool you could only get from a state intelligence agency. Every technique here is used against ordinary businesses constantly, and the defences that would have blunted this attack are the same unglamorous controls that protect any company: enforce the macro policy, watch what leaves the network, make stolen credentials hard to reuse, and run endpoint detection that flags a machine behaving strangely.

The gap between "a Russian intelligence service" and "the opportunist who phishes your accounts team" is smaller than the headlines suggest. The GRU does this at a higher tempo and against harder targets, but it reaches for the same living-off-the-land tradecraft because it works, and because it is quiet. If anything, that should be reassuring: you do not need exotic defences to raise the cost of this, you need the ordinary ones actually turned on.

What organisations should do#

1) Enforce the macro block, don't assume it#

Confirm that "Block macros from running in Office files from the Internet" is enforced by policy across your estate, not left to each machine's default, and that no one is running an Office version old enough to ignore it. Macros that must run should be signed and come from a trusted location, never enabled by a user clicking through a warning. If your staff still receive and open macro-enabled documents by email, that is the habit an attacker is counting on, and it is exactly what phishing simulation is for.

2) Watch the way out, not just the way in#

This intrusion lived or died on outbound traffic: test connections to cloud services to find an open channel, a backdoor fetching tasks from a webhook service and then a raw IP, and an SSH tunnel carrying data back out. Most organisations watch inbound far more closely than outbound. Alert on, and where possible block, outbound NTLM and SMB to the internet, outbound SSH from machines that have no business making it, and connections to webhook and API-mocking services your business does not use. The same GRU advisory lists dozens of such services worth alerting on.

3) Make stolen credentials less useful#

The attackers' whole middle game was collecting credentials to move deeper. Blunt that. Move accounts to phishing-resistant authentication, passkeys or security keys rather than passwords and one-time codes, as covered in our guide to passwords and MFA. Reduce reliance on NTLM and plan its retirement. Separate privileged accounts so one captured credential does not open the whole estate. And don't lean on a single control: as we wrote in why MFA alone isn't enough, a stolen session or a coerced handshake can walk straight past a login prompt.

4) Hunt for the specific signs#

If you run Windows at any scale, it is worth looking for both the indicators and the behaviours. The concrete markers Symantec published include the command-and-control server at 185.82.218[.]119, a reflective loader named ld.exe (SHA256 f1cc91e7427a22027f65d31bbee19c54b602d08d7d93e4745b9cea59fa8132ff) run alongside an encrypted Events.dat, a planted id_rsa key file in a fake C:\ProgramData\Adobe path, and several webhook.site endpoints. More durable than any single indicator are the behaviours: a one-pixel, off-screen or headless Edge window loading a data: URL, ssh.exe opening a backgrounded outbound tunnel, a PowerShell listener on localhost paired with a loopback net use, and scheduled tasks launching scripts from user-writable folders. The full indicator list is in Symantec's report.

5) Treat a found backdoor as a live intrusion#

The report's closing warning is the one most likely to be ignored. The infrastructure was still present weeks after the operators finished, and a launcher reappeared two months later. If you find a HOOKEDGE indicator, or any backdoor, do not assume the story ends at the malware. Assume credentials were taken and a route inward was built, and go looking for the tunnelling and credential theft rather than cleaning up the one file you found and calling it done. A server patched today that was compromised last month is still compromised.

If you supply someone who is a target#

You do not have to be the defence manufacturer to be caught up in this. The same GRU unit has a documented habit of pivoting from a primary target to the smaller companies that do business with it, exploiting the trust between them to get a foothold. If your firm supplies, services, or shares systems with organisations in defence, maritime, aerospace, logistics, or government, you are part of someone's attack surface whether you feel like a target or not. The practical implications are the ones above, plus a hard look at the standing access and trust your partners' networks have into yours, and yours into theirs.

What to watch next#

• What the payload was. The encrypted file was never recovered, so what APT28 ultimately ran on the shipbuilder is unknown. If a later report identifies it, that will tell us what the operation was really for.
• Whether the countries or companies are named. Symantec named neither. Government statements sometimes follow these reports, sometimes not.
• Whether other APT28 targets show the same follow-on. Symantec found the heaviest activity at the shipbuilder but flagged the law enforcement agency and the aircraft-engine maker too. Whether those saw the same credential theft and tunnelling is not yet public.

Summary#

1. Confirmed: Russia's APT28 breached a NATO naval shipbuilder, stole credentials two ways, and ran a persistent SSH tunnel into the internal network. The foothold stayed live for about two months.
2. Unknown: the final payload was never recovered, so what the attackers ultimately installed, and whether data was taken, is not established.
3. The method was ordinary: a Word macro, a hidden browser window, the built-in Windows SSH client, and a PowerShell script. No zero-day, no exotic malware.
4. The defences are ordinary too: enforce the macro block, control outbound traffic, retire NTLM and move to phishing-resistant MFA, and run detection that flags odd machine behaviour.
5. A found backdoor is a live intrusion: hunt for the credential theft and tunnelling, not just the one file, and assume the attacker went deeper.
6. Supply chains are in scope: this group pivots from primary targets to their smaller suppliers, so proximity to a sensitive sector is its own exposure.

Not sure whether your macro policy is actually enforced, what your network is quietly sending out, or how far an attacker could move from one phished login? Get in touch - bluwarden can review your exposure, hunt for signs of compromise, and help you turn the boring controls that stop attacks like this one. See what our services cover.

This article reflects Symantec's 20 October 2026 report and related public reporting as of that date. The attackers' final payload was not recovered, the affected countries and companies have not been named, and details may change as more is published.