Most malware you read about wants files, which means documents, credentials, or customer records, and the damage gets measured in what was copied and how many people were affected. There's a smaller and more dangerous category that wants something else entirely, which is the cryptographic key material that protects your traffic, and the loss in that case isn't a set of files but the confidentiality of the network itself.

That distinction changes everything downstream, because a stolen database is a breach you can scope and close, while a stolen key is a standing capability that keeps working after the malware is gone, and it does so invisibly, because decryption performed with a legitimate key produces no errors, no alerts, and nothing in the packet capture that looks out of place.

So here is how this class of attack actually works, why network controllers are the natural target, how to look for it, and why the recovery is a rebuild rather than a cleanup.

Important Disclaimer

This article is intended for educational and defensive purposes only, and it describes general attack patterns and defensive practices rather than specific incidents or vendor advisories. Detection guidance depends on your platform, your logging, and your architecture, so validate every check against your own environment and involve your incident response lead before acting on a production network. 

Do not run destructive commands on a suspected device, and preserve volatile evidence before rebooting anything. The author assumes no liability for missed detections, business outcomes, or damages resulting from the use or misuse of this information.

Why Key Material Is the Real Target

Encryption is usually described as protecting data in transit, and what that really means is that two devices agree on a secret, and everything between them becomes unreadable to anyone who doesn't have it. The traffic can be captured freely, because without the secret it's noise.

So if an attacker obtains the secret, they don't need to break anything, intercept anything, or maintain a foothold in your network, because they can decrypt traffic they captured before the intrusion was discovered, and they can decrypt traffic they capture afterwards, and they can do both from outside your infrastructure with nothing but a copy of the key.

That's the difference between an intrusion and a capability, and it's why the question after an incident like this isn't "what did they take" but "what can they still read."

Why Controllers Are the Natural Place to Look

In most enterprise networks, the devices that hold and distribute traffic keys are controllers, which exist to manage the tunnels between sites and to hand out the key material each site needs to talk to its peers.

A controller is therefore a concentration point, because it isn't protecting its own traffic, it's protecting everyone else's, and it holds key material for many edges at once. That makes it a far more attractive target than any individual router, because compromising one device can yield keys for an entire estate rather than for a single site.

The second reason controllers get targeted is architectural, which is that they're often appliances running a hardened Linux base with vendor services on top, and they're managed by a small team, patched on a slower cadence than application servers, and rarely instrumented with the endpoint monitoring that a general-purpose server would have.

The Two Ways to Get the Keys

There are broadly two ways an attacker gets key material, and they call for different detection.

The first is to steal the stored keys, which means reading them from disk, from a configuration store, or from a secrets backend, and this requires filesystem access and leaves file access artefacts behind.

The second, which is more interesting and harder to catch, is to read the keys in memory after decryption, which means letting the device do its normal job of decrypting control traffic and then reading the result before it's used. This is powerful because it defeats encryption entirely without breaking it, since the attacker is reading what the device already decrypted for itself.

The second technique is why detection has to focus on processes and service definitions rather than on network traffic, because the traffic looks exactly as it should.

How This Kind of Malware Hides

Malware on a network appliance can't rely on the tricks that work on a workstation, because there's no user to click anything and the environment is locked down, so it typically does three things.

• It anchors to the service manager, which means it modifies or adds a service definition so its own code starts at boot alongside the legitimate daemons, and this is the most reliable place to look because the modification has to persist across restarts to be useful.
• It injects into an existing process rather than running its own, which means there's no suspicious new daemon listening on a port, and instead the malicious code lives inside a process that's supposed to be there and is therefore trusted by everything around it.
• It copies timestamps from legitimate files so a directory listing doesn't reveal that anything is newer than it should be, which works against a casual glance but is much harder to sustain against inode change times, because mtime can be set with a tool and ctime cannot be forged without changing the filesystem itself.

Looking for It: The Checks That Actually Pay

The useful principle is to compare your device against its own baseline rather than to hunt for signatures, because this class of malware has to modify something that was previously known-good, and that modification is visible.

Start with the service definitions. Every service manager has a directory of startup definitions, and the legitimate ones for your platform version are known and documented, so read them and look for anything before the expected service start.

ls -la /etc/sv/ /etc/systemd/system/ 2>/dev/null
cat /etc/sv/*/run 2>/dev/null | head -80

What you're looking for is a script that remounts a filesystem writable, launches a background helper, or invokes a binary that isn't part of the platform.

Then check for compiled binaries where there should be scripts. Network appliances often implement management services in Python or shell, so a compiled ELF in a service directory is a mismatch worth explaining.

find /etc/sv /etc/systemd/system -type f 
-exec file {} \; 2>/dev/null | grep ELF

Then inspect the process maps of the daemons that handle encrypted connections. If a shared object appears in a daemon's memory that doesn't exist on disk from the vendor package, something loaded it at runtime.

ps aux | grep -E 'vdaemon|strongswan|charon|ipsec'
for p in $(pgrep -f 'vdaemon|charon'); do echo "== $p"; 
grep -E '\.so' /proc/$p/maps; done

Then check the shared memory and temporary directories for staging files, because collected key material has to sit somewhere before it leaves.

find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls 2>/dev/null

Then verify file integrity against the package manifest, because a replaced system binary means the device can no longer be trusted to report on itself.

rpm -Va 2>/dev/null | head -40
debsums -c 2>/dev/null

Then look at timestamps properly, comparing modification time against inode change time, because the gap between them is where timestamp copying shows up.

stat /etc/sv/*/run 2>/dev/null

And finally, hunt the access rather than the payload, because whatever got the attacker in may be visible in authentication and audit logs even when the implant is clean.

last -a | head -40
grep -iE 'accepted|session opened' /var/log/auth.log 2>
/dev/null | tail -50
journalctl -u ssh --since '-14 days' 2>
/dev/null | grep -i accepted

Why Cleaning Doesn't Work

The instinct after finding malware is to remove it, and on a network controller that instinct is wrong, for a reason that's worth stating plainly.

You cannot prove a device is clean by deleting the thing you found, because the whole point of this class of malware is to be one of several things, and finding one component tells you nothing about whether there's another in a place you didn't look. A modified shared library, an added kernel module, a second service definition, or a patched vendor binary all survive the removal of the first artefact you noticed.

And even if you achieved a genuinely clean device, you would still have the original problem, which is that the key material has already left, so the confidentiality of the traffic is already lost regardless of what the device looks like now.

So the correct response has two parts, which are rebuild and rotate, in that order, and neither is optional.

The Order of Operations

The sequence matters more than the individual steps, because doing them in the wrong order destroys evidence or leaves access in place.

• Preserve before you touch anything. Capture the process tree, the open sockets, the loaded modules, the service definitions, and if the incident warrants it, a memory image, because all of that dies on reboot.
• Isolate rather than power off. Removing the device from the network stops the exfiltration and keeps the evidence intact, while pulling the power achieves the first and destroys the second.
• Rebuild from a known-good image. Not a restore from a backup taken after the compromise, and not a clean-up of the existing filesystem, because both assume the thing you're trying to verify.
• Rotate the key material. This means every key the device held, and it means treating the traffic that traversed those tunnels as potentially readable, which is a decision that belongs with your risk owner rather than your network team alone.
• Rotate the credentials too. The device held credentials for everything it talked to, which typically includes management accounts, API tokens, and trust relationships, and leaving any of them in place leaves the attacker a route back in.
• Then investigate. Only after containment is it worth spending time on how they got in, because the answer changes your patching priority but doesn't change the rebuild.

Real Two Scenarios

Scenario 1: The Patch That Ended Nothing

The Setup

A network team patches a controller for a known authentication weakness within days of the vendor advisory, confirms the version is current, and closes the ticket, because the vulnerability scanner no longer flags the device.

What Happened

The patch closes the way in and does nothing about anything already inside, so a modified service definition that was placed before the patch continues to start a helper at every boot, and the helper continues to read decrypted control traffic.

The Result

Weeks later, an unrelated troubleshooting session turns up a staging file in /var/tmp, and the investigation establishes that collection continued after the device was considered remediated, which turns a contained vulnerability into a long-running exposure of key material.

The Lesson

Patching answers whether they can get in again and says nothing about whether they're still there, which makes post-compromise investigation a separate step rather than a follow-up to a change ticket.

Scenario 2: The Baseline Comparison

The Setup

Another team runs a configuration review after reading about this class of attack, and instead of scanning for malware it compares the controller's service definitions against the baseline from its own build image.

What Happened

One service script contains two lines before the legitimate start, one remounting a filesystem writable and one launching a helper in the background, and a compiled binary sits in a directory where the platform expects a script.

The Result

The controller is isolated rather than rebooted, volatile state is preserved, the rebuild proceeds from a clean image, and the key rotation is scoped to the peers the device actually served rather than the whole estate.

The Lesson

The cheapest detection was a file comparison rather than a signature, because the malware has to modify a service definition to survive a reboot, and that modification is visible to anyone holding a baseline.

How to Spot Early Warning Signs

• A service script has lines before the expected service start. That is the most reliable single check on this class of device.
• A compiled binary appears where the platform uses scripts. Mismatched file types are a strong signal.
• A shared object appears in a daemon's memory that isn't on disk. Something loaded it at runtime.
• Files exist in /tmp, /var/tmp, or /dev/shm that the platform didn't create. Collection has to stage somewhere.
• Package integrity checks fail. A replaced binary means the device can't be trusted to report accurately.
• Modification times and inode change times disagree. Timestamp copying is hard to sustain against ctime.
• Administrative logins appear from unexpected sources. Hunt the access even when the payload looks clean.
• A device behaves normally while its configuration drifts. Subtle config changes around management access deserve attention.

Quick Reference: Where to Look on a Controller

The Bottom Line

Malware that targets key material is a different problem from malware that targets data, because it doesn't need to hold anything after it succeeds, and it doesn't need to break encryption when it can read what your device already decrypted. Controllers are the natural target because they concentrate key material for many sites at once, and they hide well because they modify service definitions and inject into processes that are supposed to be running.

The defensive position is uncomfortable but simple, which is that a patched device is not a clean device, that service definitions are the cheapest place to look, and that a confirmed compromise means rebuild and rotate rather than delete and hope.

So compare your controller's startup definitions against your build image this week, because it takes ten minutes and it's the one check this class of malware cannot avoid leaving behind.

FAQ

Why is stolen key material worse than stolen data?

Because a key is a capability rather than an object, so it keeps working after the malware is removed and after the vulnerability is patched, and it can be used to decrypt traffic without maintaining any foothold in your network.

Why do attackers target network controllers rather than individual routers?

Because a controller concentrates key material for many sites at once, so compromising one device can yield keys for an entire estate rather than for a single location, and controllers are often patched and monitored less aggressively than application servers.

How does malware read encrypted traffic without breaking the encryption?

By letting the device do its normal job of decrypting and then reading the result before it's used, which is typically achieved by injecting code into the daemon that handles encrypted connections rather than by attacking the cipher itself.

Where should I look first on a suspected controller?

At the service definitions, because malware on an appliance has to start at boot alongside the legitimate daemons, so a script with extra lines before the expected service start is the most reliable single indicator.

Why is the gap between mtime and ctime useful?

Because modification times can be set by anyone with write access, while inode change times cannot be forged without altering the filesystem, so a file whose timestamps look old but whose ctime is recent has likely been tampered with.

Can I clean a compromised controller instead of rebuilding it?

No, because finding one component tells you nothing about whether another exists somewhere you didn't look, and a modified library, an added service definition, or a replaced binary all survive the removal of the artefact you noticed.

What has to be rotated after a controller compromise?

Every key the device held and every credential it used, which typically means the traffic keys for the peers it served, management accounts, API tokens, and trust relationships, because any unrotated secret leaves the attacker a route back in.

What is the correct order of operations?

Preserve volatile state first, isolate the device from the network without powering it off, rebuild from a known-good image, rotate keys and credentials, and only then investigate how the attacker got in.