Threat intel

APT28 breaches a NATO naval shipbuilder with HOOKEDGE

By Yaali. October 25, 2026, 6 min read, Threat intel, Phishing, Windows.

Symantec says Russia's APT28 spent two months inside a European naval shipbuilder. How the Word macro, SSH tunnel and loader worked, and what to hunt for.

On October 20, Symantec's Threat Hunter Team published details of an espionage campaign against organizations in two NATO member states: a naval shipbuilder, a law enforcement agency and a manufacturer of military aircraft engines. The intrusion at the shipbuilder succeeded. Symantec tracks the operators as Swallowtail, its name for APT28, the group also known as Fancy Bear, Forest Blizzard and BlueDelta, which the US government links to Russia's military intelligence service, the GRU.

Symantec did not name the countries or the victims beyond saying they are in Europe. First infection at the shipbuilder was on July 24, 2026, and the last activity Symantec saw was on September 24. If you build, supply or support defence, maritime or aerospace programmes in Europe, treat the published indicators as a hunt list for this week. Symantec also could not tell whether data was stolen, which is a reason to look rather than assume.

How the intrusion worked

The way in was a macro-enabled Word document sent as an email attachment. The VBA macro was obfuscated by splitting its code and strings into fragments joined at run time, which defeats simple signature scanning. Its AutoOpen routine dropped four files into the user profile: a VBScript launcher, a batch script, and an HTML and XHTML pair that auto-submits a hidden form.

That is HOOKEDGE, a backdoor Recorded Future's Insikt Group first documented in August 2026 and assesses as the successor to HEADLACE, an APT28 implant from 2023. HOOKEDGE has no compiled binary. The batch script kills running Edge processes, then opens a 1x1 pixel, off-screen Microsoft Edge window and hands it base64-encoded JavaScript that fetches a task from webhook.site, a free service for receiving HTTP requests. The batch script runs the task and posts the output back through Edge. To a proxy, all of this looks like the user's browser talking to a popular website.

About two minutes after the document was opened, the operators sent a reconnaissance task. It probed outbound reach to Dropbox, Google, Microsoft login, Mega and a hard-coded IP, 23.220.75.245, read proxy and WPAD (Web Proxy Auto-Discovery) settings, and listed sessions, network configuration, processes and the user's folders. The likely purpose was to learn which exfiltration routes were open.

After three quiet days, a second stage arrived on July 27 and moved command and control off webhook.site to a dedicated server, 185.82.218.119 on port 443. Seven tasks ran in about 30 seconds, a pace Symantec reads as a person at the keyboard.

Credentials and the tunnel

The operators took credentials two ways. First, they pushed a file to the host, renamed it id_rsa and placed it in C:\ProgramData\Adobe\, changing its ownership and permissions to a named local account. OpenSSH refuses private keys that other users can read, which is the likely reason for that step. Second, a short PowerShell script started an HTTP listener on localhost:8080 and ran net use against an SMB-over-HTTP path pointing at it. Windows then tried to log in to its own listener, and the script kept up to four NTLM authentication headers. Those NTLMv2 challenge and response pairs can be cracked offline or relayed to another server.

With the key in place, they ran the Windows OpenSSH client, C:\Windows\System32\OpenSSH\ssh.exe, to root@185.82.218.119 over port 80, with host key checking off and legacy ssh-rsa forced. A remote dynamic forward bound port 48097 on their server, so anything they sent to it was routed through the victim host as a SOCKS proxy into the internal network. DNS lookups and pings of internal hosts followed within minutes, along with whoami /all, net group Administrators, systeminfo and wmic qfe to check privileges and patch levels. They killed ssh.exe with taskkill on July 28.

On July 31 they ran C:\ProgramData\ld.exe with a decryption key and the path of an encrypted file, Events.dat, as arguments. The loader, which Symantec had not seen before, decrypts the file in memory, checks for the marker ADSA and calls an exported function named ExecuteLoader. Symantec never recovered Events.dat, so the final payload is unknown. The VBS launcher and ld.exe were still on the host in late August, and the launcher ran again on September 24. Symantec could not tell whether that was a leftover scheduled task or the operators coming back.

Where this fits

Recorded Future documented the same backdoor against government, diplomatic and defence manufacturing targets in Romania, Spain and Turkey between September 2025 and April 2026. Symantec describes the new targets as a collection effort "tasked broadly against European government and defense targets", and says the common thread is relevance to national security and defence policy. The move from webhook.site to an operator-owned server for a high-value victim matches Insikt's observation that better targets get a faster second stage.

What to do

No vulnerability was exploited, so there is no patch to apply. The fixes are configuration and hunting.

Block macros in files from the internet. Turn on the Microsoft 365 policy "Block macros from running in Office files from the Internet" (User Configuration, Administrative Templates, Microsoft Word, Word Options, Security, Trust Center). Add the Attack Surface Reduction rule that blocks Office applications from creating child processes, so a macro cannot start wscript.exe or cmd.exe.
Search for the indicators. Look in proxy, firewall and EDR logs for 185.82.218.119, outbound SSH on port 80, and any webhook.site URL. Symantec lists five webhook.site paths, including 53379b62-8020-41cf-af57-effa6e1e8506 and 5b73dc69-d765-4440-a4d2-e9eb33283eb9. The report also gives 17 SHA-256 hashes for HOOKEDGE droppers, three for the VBS launcher and one for ld.exe (f1cc91e7427a22027f65d31bbee19c54b602d08d7d93e4745b9cea59fa8132ff). Load the full list from the Symantec post into your EDR.
Hunt for the behaviour. The indicators will change; these patterns are harder to swap. Look for msedge.exe started by cmd.exe or wscript.exe with --headless or a tiny or off-screen window size, scheduled tasks that run .vbs or .bat files from user profile folders (Symantec saw one named 53379b62), ssh.exe with -R and -N on a workstation, any id_rsa outside a user's .ssh folder, and ld.exe or Events.dat in C:\ProgramData.
Close the side doors. Block webhook.site and similar request-catcher services at the proxy if no team needs them. Deny outbound TCP 22, and SSH on any port, from workstations. If staff do not need the Windows OpenSSH client, remove the optional feature.
If you find a hit. Isolate the host, collect memory before rebooting (the loader runs its payload in memory only), then reset the passwords of every account that logged on to it, since NTLM hashes from that host may be cracked. Review the internal hosts that were reached through the tunnel and rebuild the workstation instead of cleaning it.

The wider lesson

Until ld.exe arrived on July 31, every step of this intrusion ran on tools already present on a current Windows machine: Word, Edge, batch files, PowerShell and the built-in SSH client. Allowlisting and hash-based detection have little to grab onto in that first week. Detections built on parent and child process chains (a batch file or script host starting a hidden Edge window) and egress rules that allow only the destinations a workstation needs give a defender a chance on day one.

We test those detections in security operations and harden endpoint and egress settings in safeguarding and hardening work. If you want the Symantec indicators checked against your own logs, open the chat and Yaali, our AI agent, will pass the request to an engineer.

Sources: Symantec Threat Hunter Team, Cybersecurity Dive, The Hacker News, The Record, Recorded Future Insikt Group.